Quote:
Originally Posted by greg nice
but i'm not sure of a good automated solution, because determining whether or not you are sitting down at a table is non-trivial. a quick workaround is to use the "manual move table into grid" hotkey on the new table, that way it will have its own dedicated position in the grid, for you to decide what you want to do.
this must be a new bug, please tell me if it persists and if you notice any more consistencies when it happens. in this new version, some mouseclicks move the mouse cursor. to counter that, ive sent commands to move it back to its previous location. during testing i did not have problems. also, i don't believe fulltilt had any of these mouse movements, but ill but this bug on the radar
The main problem with failing to deal with opening tables is when the tables open actually IN (on top of) the grid area. I use table selection and often find myself on multiple waiting lists. As sods law would dictate, like buses, they all come at once
I had a situation earlier when I had 4 tables in slots all involved in a hand. In quick succession 3 tables were opened (I was seated and bought in automatically by pokershortcuts) and ALL of these new tables were in the "play" area where my 4 slots were located. It was several moments of chaos while I sorted these tables out and (sods law again) while I was doing so more tables opened as well
. Moving manually into a slot would not help because they were all full and making more slots would not be ideal because I do not want smaller slots; I do not want slots overlapping other slots and I do not want play slots off the main monitor.
These tables are of no interest to S&T until they have the "fold" (or deal me in or "play now" or "join waiting list" visible at which point they can be grabbed and stacked.
In an earlier version of your code you used lists for slotted; tablequeue, stacked and nonurgent tables. Could you not add another list for "Newtables"?
Once you have ued fulltiltlist() to get the ids, any table that is not slotted or stacked must by definition be "new". This would remain the case even after several Timer cycles. they may not be "new" any more but they are still waiting to be decided upon.
If this new table HAS a "fold" button visible (not likely) you can stack it because it was readable by S&T so can get in the queue. Even if there is no button "Play Now" tables will pop later!
However, as you say, a player may not be seated and detecting it is hard (but not impossible). A simple way (on FT) is to look for the white space of the check boxes on the LHS of the screen Sit Out and Auto Post check boxes are not visible when we are observing a table but as soon as we take a seat they become visble.
I do not know whether such simple mechanisms are possble on other sites.
The simplest solution is to detect these white areas and, if they exist, stack the new table because the player IS seated.
However, what if that does not work or if we have tables opened at which we are not yet seated?
Now the new table list may be of some use. The user could select an area (stored in the ini) in which any new tables are placed. While they are there they are the reponsibility of the user and NOT S&T. If the table is closed you simply remove it from the list as you do now for other lists and if the player wishes to they can press a stack hotkey to transfer the table to S&T's responsibilty.
When I coded this for my personal use I had enough screen space to actually cascade these new tables but a stack would work as well. You could add another hotkey to move the top table to the bottom of this "waiting" or "new" stack allowing the user to cycle through.
There is also nothing wrong with allowing S&T to grab any of these when a button shows. However, allowing a choice of S&T actions would be best I think.
Let's say that I am currently playing 6 tables with 4 in slots. The ideal solution for me is that when my waiting list tables open they open somewhere that does not interfere with my current 6 tables and where I could look at the new table and decide whether to play it or not. This would be just as useful even if I did not immediately take the seat. There seems little point in adding to the work of the S&T by shuffling these tables into a play slot to look at. When I decide I can close the table or put it in the stack where S&T takes over.
However, I can fully appreciate that others may not want this separate stack and would prefer everything to move into the main stack ASAP. To cover this an option that says "New table at which we are seated to go to main stack Y/N" would either put the new/seated table into the main stack of the "holding" stack/cascade.
Hope this helps.
I played a second session today and if anything the mouse grab problem was even worse. I will continue to monitor it. This is a deal breaker! I could be sending hotkeys to all sorts of places
However, I still "sense" that it is going to the stack but that could be wrong.
Cheers
T