Open Side Menu Go to the Top
Register
TableNavigator TableNavigator

02-18-2006 , 01:31 PM
Thanks juk.

Did you just resize the sidebet windows to one pixel? Because those might be the "invisible" windows?
Just strange because it can't detect invisible windows actually. Then again, that GUI - can do just about anything...
TableNavigator Quote
02-18-2006 , 01:37 PM
Hehe, I think is is maybe something to do with the sidebets now you mention it!

The 'invisible' window was about 1/2 way down on two of my party tables (just where the sidebet used to be).

I deleted them off my disk totally this time, but in the old beta I did resize to 1 pixel (hoping they wont come back this time like they used to!).

Hopefully this fix will avoid sidebet windows forever and it also avoids the problems I was having with HH windows sometimes being treated as tables.

Quote:
Just strange because it can't detect invisible windows actually. Then again, that GUI - can do just about anything...
Yep, it seems to have supernatural powers, but it does work great!

Juk
TableNavigator Quote
03-06-2006 , 03:40 PM
Bump.

Still using this script all the time and have alot to thank Roland for:

- Way less arm pain that with the old mouse setup I had before (= more hours of poker possible).

- Played all weekend and not a single misclick (which was rare even for the mouse). The coloured bar which moves around is by far the best method of identifying the active table I seen yet and avoids most misclicks.

I suggest anybody else who wants to try 'mouseless poker', to try using this script

For anybody who wants to try it, then the newest version can be found in this sub-thread.

TY again! - Juk
TableNavigator Quote
03-06-2006 , 06:18 PM
That's right - don't let it die.

I know I said "Lobby control tomorrow" like a month ago - sorry for that but it's definitely the first thing I'll do once iWitness is up and running... hopefully, err, tomorrow.
TableNavigator Quote
03-06-2006 , 06:21 PM
Hey, no rush for the lobby control. It helped me alot just the way it is!

Juk
TableNavigator Quote
03-07-2006 , 01:01 AM
Quote:
Hey, no rush for the lobby control.
What lobby control are we looking for? Like "open new table"? "Get on waitlist"?

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

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...
TableNavigator Quote
03-07-2006 , 01:28 AM
Quote:
the problem is to find a smooth and user-friendly way to handle all the different situations that can come up (no good if you can never remember which button does what ).
In my scripts, I've always worked to maintain a sort of "Red, Yellow, Green" pattern in rows of buttons. For instance, my bottom row is "Fold, Call, Raise". My 2nd row is "Don't post, wait to post, post".

For alted-rows, when a waitlist opened up for me, I had "Deny new seat, , accept new seat". For lobby control, I had "Close current table, , Waitlist for new table". (Note that the middle button is empty on both of these. No big deal. I have room for 12. ) What other commands can you think of? I thought about maybe defining another alt key which turns the direction-pad into a mouse. Don't know if that'd be useful.

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.)
-Sam

P.S. "Oh, Roland and Juk are writing a joystick script.", I thought. "I didn't get in on that project early enough. That's ok, though; I'll sit out on this one. Maybe I'll even play some poker. Or write my [censored] thesis." Of course not.
TableNavigator Quote
03-07-2006 , 12:25 PM
I really don't know what would work best for this?

Just the fact that now I can play my tables without the mouse seems to have removed most of the strain I was getting before. I currently only use 5 buttons: Fold, Call, Raise, Post/Check-Auto-Post and the (magic!) Fix-GUI button.

I found that using this mixed with the AutoResizer util, I use the mouse very rarely now. Only situations I can think of are:

1. Choosing a seat, sitting down (AR auto confirms everything, so this just 1 click).
2. Leaving the table (also auto confirm the leave dialog).
3. Activating the lobby.
4. Joining a waiting list or joining a table (also use AR to auto-confirm these).

And that's pretty much it now. I was thinking about adding something along the lines of this UI, but not sure if it will be any good:

When I hold down a certain modifier the Lobby is activated (and stays activated). Then use up/down on the D-Pad to move up/down the list of tables and have a button which either takes you to the table if there is a free seat, else adds you to the waiting list.

Perhaps also have another button or combination which will select a seat and another combination (possibly all joypad buttons to together) to leave a table.

Again though, I got no idea how helpful this would be, and seems like the setup I have at the moment works pretty nicely as it is. I tried adding quick-fold hotkeys to AutoResizer, but found them to be pretty hard/unintuitive to use, and not sure if lobby control would be like this too?

Does anybody here play using purely JoyPad control? If so, I guessing you get the bot test a lot if you do this?

Juk
TableNavigator Quote
03-07-2006 , 12:43 PM
Quote:
I thought about maybe defining another alt key which turns the direction-pad into a mouse. Don't know if that'd be useful.
Not sure how helpful this would be though? The sample AHK script which does this is pretty hard to use. I remember many years ago the Amiga had a pseudo-mouse which had some kind of momentum term added. This made it quite usable, as it allows for fine grained control for small distances, and for longer distances wasn't too slow either.

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.)
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!

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:
P.S. "Oh, Roland and Juk are writing a joystick script.", I thought. "I didn't get in on that project early enough. That's ok, though; I'll sit out on this one. Maybe I'll even play some poker. Or write my [censored] thesis." Of course not.
I know this feeling well, distractions, distractions, distractions...

Juk
TableNavigator Quote
03-07-2006 , 12:45 PM
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.
TableNavigator Quote
03-07-2006 , 01:02 PM
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.)

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!

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..).

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.
TableNavigator Quote
03-07-2006 , 01:03 PM
Quote:
I've got it all seat up, but the damn disappearing Guibar was slowing me down.
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.
This does make sense and sounds much better than my ideas on holding down combinations of buttons!

Hope the headache goes soon - Juk
TableNavigator Quote
03-07-2006 , 01:08 PM
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.

I actually found the bug(s) and I should be able to fix 'em.
TableNavigator Quote
03-07-2006 , 01:34 PM
Quote:
I'm happy to work on this project, too. I feel a little embarassed that my name is already included.
-Sam

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

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...
I've never been good at naming anything. Go for it.
TableNavigator Quote
03-07-2006 , 01:49 PM
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...
I've never been good at naming anything. Go for it.
Hmmmm, your not the only one! AutoResizer kinda does everything but AutoResize now, but I guess I stuck with the legacy name...

Hopefully alot of its ideas will get merged into PartyPlanner eventually, so won't be stuck with this name forever!

Juk

EDIT: Hmmmm, DollarToBB when it gets the blinder stuff added... I gotta think more before naming stuff...
TableNavigator Quote
03-07-2006 , 01:54 PM
Quote:
Hmmmm, DollarToBB when it gets the blinder stuff added... I gotta think more before naming stuff...

AutoBB.
TableNavigator Quote
03-07-2006 , 02:45 PM
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.
So, "seating" mode means actually sitting down at the table, right? Like choosing between Seat1 and Seat2. I'd forgotten about this mouse-need.

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
TableNavigator Quote
03-07-2006 , 02:58 PM
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.
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.
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.

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.
TableNavigator Quote
03-07-2006 , 03:02 PM
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.)
Yes, this sounds pretty good idea. I think alot of people would use this GUI if they found it easy to setup
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
TableNavigator Quote
03-07-2006 , 03:07 PM
Quote:
Do we want to change it so it listens to the joystick natively?

I'd like to make this configurable, yeah.
TableNavigator Quote
03-07-2006 , 03:09 PM
Quote:
Quote:
I'd forgotten about this mouse-need.
No mouse involved, hehe. You'll like the code I think. It's pretty.
Sure. I just meant that I had composed a list of all the poker things I do with a mouse, and choosing a seat was off my list. I'm sure I'll like the code. I envisioned a moving highlight over each available seat in turn. Do you highlight the seats in "a blue you quite like"?

Do we need to let the user switch between tables that have free seats? Maybe we just let them navigate between free seats at this table or cancel this table. That way "seat mode" locks you in the first table with available seats, and you can take it or leave it.

I often get a bug where the lobby sends me to a table, but the seat still says "reserved". I have to actually remove myself from the waitlist, and then it's immediately available. Are we gonna have to code that?
-Sam
TableNavigator Quote
03-07-2006 , 03:10 PM
I think this might help some who find stuff like this hard to edit. I know AHK easy to edit for us, but some who might like to use this script may find this a bit daunting and an easy to follow dialog to help setup to controls might help these people?

Juk
TableNavigator Quote
03-07-2006 , 03:24 PM
Quote:
Do you highlight the seats in "a blue you quite like"?

Lol. This is gonna be configurable too.

Quote:
Do we need to let the user switch between tables that have free seats? Maybe we just let them navigate between free seats at this table or cancel this table. That way "seat mode" locks you in the first table with available seats, and you can take it or leave it.

Now this is getting complicated. I don't think I ever open two potential new tables at once, but it's hard to find 4 decent stud tables at all so that might be the reason.
So actually, you want it, you code it.

Getting aroung the reserved seat bug should be simple, no?
Or not so simple if we use PixelGetColor or something to completely automate it, I guess.
TableNavigator Quote
03-07-2006 , 03:24 PM
There's a joystick test script here. It kinda sucks, though.

I was envisioning a page with 1 row for each possible joystick button. (10 rows, I guess.) When you push a button, that row lights-up.

Each row has 4 pulldown menus; 1 for each mode. So row 1, column Play, you have a menu containing "fold, call, raise, don't post, wait to post, post".

That sound about right?
-Sam

P.S. The only problem with putting "Close Table" in the Play mode is that it's the 7th command. What happens if they only have 6 buttons?
TableNavigator Quote
03-07-2006 , 03:28 PM
Quote:
What happens if they only have 6 buttons?
They invest 30 bucks in a decent pad?
TableNavigator Quote

      
m