TableNavigator

[Roland]

Okay, here's the basic setup:

We have 4 different "modes" (stole this idea from Waffle). I called them "Play", "Lobby", "Dialog" and "Seating".
You can toggle in and out of these modes with a single key (button). Advantage is that you don't have to hold down a modifier (point of this thing is to reduce strain, right?) and that you only use one button.
What these modes are:
"Play" is play, obviously.
In "Lobby" mode, you can browse through the List- or TreeView, open tables or click the Join Wait List button.
"Dialog" mode handles any (Party) window that is not a table or the lobby. 'Course, AR does most of this, but we still need it for the Seat Available window, the dialog that pops up when you close a table etc.
In "Seating" mode you can choose a seat.

I've got it all seat up, but the damn disappearing Guibar was slowing me down.

Edit: Just realized this is very brief and confusing. This is probably because the code is very long and confusing and I've got a slight headache. I need some coffee.

[Roland]

[ QUOTE ]
[ QUOTE ]
Since this has a pretty gui, it might be nice to let the user specify which button does what. It'd also let them test which buttons are which. (Light-up a "1" when button1 is pushed. etc.)


[/ QUOTE ]
Yes, this sounds pretty good idea. I think alot of people would use this GUI if they found it easy to setup - its saved me a great deal of arm ache so far!


[/ QUOTE ]

Yeah, I want to add that. Problem is I want to use both, what are they called, axii (??) on my joypad (one for moving the gui bar, one for lobby control), but I think some have only one. So this has to be optional. And the d-pad is a factor too.

[ QUOTE ]
I also wondering if there may be a way to adapt this so that (extremely) overlapping tables were handled (without all the random focus stealing which makes overlap such a pita). If I look into it more, then it will be possible to totally block party from doing the focus stealing by blocking/filtering its message queue, and this would allow AHK to control which window gets focus using some other system of control. The reason I like this idea over MTH idea, is simply the spacial aspect - it is much easier (for me) to remember players if you have some kind of 'spacial handle' on where they are seated in relation to the layout and I think this would probably be just the same with overlap?

I used to 8/10 table on 1 monitor using window's cascade and even then I had some kind of 'spacial handle' on players based on the cascade level (until I had to hit cascade again that was...). When using MTH, I found I only really remembered what had happened in one particular hand, and rather than a 'spacial handle' to a table, I use my seat position and my hole cards to remember the previous action of the hand for that table (meaning no carry over of info from one hand to another..).


[/ QUOTE ]

Should be doable. This thing has proven itself pretty flexible so far.

I have some more plans for it too, but one thing at a time. [img]/images/graemlins/smirk.gif[/img]

[jukofyork]

[ QUOTE ]
I've got it all seat up, but the damn disappearing Guibar was slowing me down.

[/ QUOTE ]

I looked over the code for the disappearing Guibar, but I not seen any fix for it yet either. It seems like a AHK specific thing which cannot be explained. I have found that I very rarely have to restart the script, and just bash the GUI-Show button and waggle the D-Pad a few times and usually its all back working fine again.

[ QUOTE ]
Edit: Just realized this is very brief and confusing. This is probably because the code is very long and confusing and I've got a slight headache. I need some coffee.

[/ QUOTE ]

This does make sense and sounds much better than my ideas on holding down combinations of buttons! [img]/images/graemlins/smile.gif[/img]

Hope the headache goes soon - Juk [img]/images/graemlins/smile.gif[/img]

[Roland]

[ QUOTE ]
I looked over the code for the disappearing Guibar, but I not seen any fix for it yet either. It seems like a AHK specific thing which cannot be explained. I have found that I very rarely have to restart the script, and just bash the GUI-Show button and waggle the D-Pad a few times and usually its all back working fine again.


[/ QUOTE ]

I actually found the bug(s) and I should be able to fix 'em.

[Roland]

[ QUOTE ]
I'm happy to work on this project, too. I feel a little embarassed that my name is already included.
-Sam


[/ QUOTE ]

Cool - I'll try to come up with a "stand-alone" version because this is all tangled up in the rest of the code. [img]/images/graemlins/smile.gif[/img]
Your name is included because your functions are included. I excluded your name from the version for Absolute though, ha. [img]/images/graemlins/grin.gif[/img]

[ QUOTE ]
P.S. By the way, can I edit Roland's first post to accurately portray the title of the script? He's never been especially good at naming AHK threads...

[/ QUOTE ]

I've never been good at naming anything. Go for it.

[jukofyork]

[ QUOTE ]
[ QUOTE ]
P.S. By the way, can I edit Roland's first post to accurately portray the title of the script? He's never been especially good at naming AHK threads...

[/ QUOTE ]

I've never been good at naming anything. Go for it.

[/ QUOTE ]

Hmmmm, your not the only one! AutoResizer kinda does everything but AutoResize now, but I guess I stuck with the legacy name... [img]/images/graemlins/smirk.gif[/img]

Hopefully alot of its ideas will get merged into PartyPlanner eventually, so won't be stuck with this name forever! [img]/images/graemlins/smile.gif[/img]

Juk [img]/images/graemlins/smile.gif[/img]

EDIT: Hmmmm, DollarToBB when it gets the blinder stuff added... I gotta think more before naming stuff... [img]/images/graemlins/laugh.gif[/img]

[Roland]

[ QUOTE ]
Hmmmm, DollarToBB when it gets the blinder stuff added... I gotta think more before naming stuff...


[/ QUOTE ]

AutoBB. [img]/images/graemlins/wink.gif[/img]

[SamIAm]

[ QUOTE ]
We have 4 different "modes" (stole this idea from Waffle). I called them "Play", "Lobby", "Dialog" and "Seating".
In "Lobby" mode, you can browse through the List- or TreeView, open tables or click the Join Wait List button.
"Dialog" mode handles any (Party) window that is not a table or the lobby. 'Course, AR does most of this, but we still need it for the Seat Available window, the dialog that pops up when you close a table etc.
In "Seating" mode you can choose a seat.

[/ QUOTE ]So, "seating" mode means actually sitting down at the table, right? Like choosing between Seat1 and Seat2. I'd forgotten about this mouse-need. [img]/images/graemlins/frown.gif[/img]

However, I don't understand why you need both "Dialogue" mode and "Lobby" mode. Could we have up/down control the lobby and left/right pan between dialogues? Block all but the Waitlist Popups, and the only commands I can think of are<ul type="square">[*]Accept Waitlist[*]Reject Waitlist[*]Open LobbyFocused table[*]Wait for LobbyFocused table[*]Wait for any table with X people[/list]Which mode does "Get up from seat and close table" fall into? I think it could go in "seating" mode, since that mode seems empty.
-Sam

[Roland]

[ QUOTE ]


So, "seating" mode means actually sitting down at the table, right? Like choosing between Seat1 and Seat2. I'd forgotten about this mouse-need.

[/ QUOTE ]

No mouse involved, hehe. You'll like the code I think. It's pretty.

[ QUOTE ]
However, I don't understand why you need both "Dialogue" mode and "Lobby" mode.

[/ QUOTE ]

It's user-friendlier. That way, we can use the same button for opening a table in lobby mode and clicking "ok" in dialog mode, for instance.
They are quite similar though, you're right.

[ QUOTE ]
Which mode does "Get up from seat and close table" fall into? I think it could go in "seating" mode, since that mode seems empty.


[/ QUOTE ]

Closing the table falls into "play" mode since we can assume you want to close the table under the gui bar; whereupon we switch into dialog mode automatically so you can confirm that you really want to leave. Whereupon we switch back into play mode.
Automating is AHKs thing, after all. [img]/images/graemlins/smirk.gif[/img]

[SamIAm]

[ QUOTE ]
[ QUOTE ]
Since this has a pretty gui, it might be nice to let the user specify which button does what. It'd also let them test which buttons are which. (Light-up a "1" when button1 is pushed. etc.)

[/ QUOTE ]Yes, this sounds pretty good idea. I think alot of people would use this GUI if they found it easy to setup

[/ QUOTE ]I just realized that the script only looks for !1, !2, etc, and relies on the user to make their joystick send the keycommands.

Do we want to change it so it listens to the joystick natively?
-Sam