i had a conversation with stars support/security recently on the subject. HUDs are allowed, but there s no obvious way to get the required data for them. so i wondered how PokerTracker (and others) are doing this. all i have is the somewhat cryptic sttement from stars that while they can not disclose what PT does they don't mind them doing so. and that intercepting messages (on the windows client) is not considered a breach their ToS. chances are i am overlooking something obvious, but poking around in the client i could not get much of the required information:

- from the log file one could potentially take number of players being dealt in a hand and their seat numbers
- from tables child window with class name "PokerStarsNoteSelectorClass" one can get the list of players seated (in cash-game this list may contain players from other tables and players who already left)
- hand histories are useless for the task because they get send from server to client no sooner than when a hand is completed. for zoom poker this means that the user may be seated many hands away when this happens.

the missing piece of information is a mapping from player names to seat numbers. so here comes the challenge: how to obtain data regarding this from the client ? as a note: any form of OCR is ruled out for, as i hope obvious reasons. and yes, all code here should be open source.


to make a start, here is what i found out about the "PokerStarsNoteSelectorClass" child window:
it behaves like a standard ComboBox, that is you can send CB_* messages to it as defined in comctrl.h.

- (CB_GETCOUNT, wParam 0, lParam 0) will get you the number of items in the notes box
- (CB_GETLBTEXTLEN, wParam indexItem, lParam 0) will get you the text length of the specified item
- (CB_GETLBTEXT, wParam indexItem, lParam buffer) will get you the actual item text, crossing application boundaries (love or hate windows for that)


whenever i find out something more i will update this thread. hopefully other interested coders will join the challenge to make it a real fun project. feel free to comment or ask questions. i will try my best to answer them.

I always assumed that the hand history file was updated as the hand was being played?
*edit* - Read somewhere that programs are using the chat box

no. the hand gets written to disk when the hand is finished. i would even assume that the text is sent from the server to the client so that nothing is in memory that could be read before it the hand is actually over. note that this is an assumption so far, i could be wrong.

this was possible up to some point when stars closed this hole and stopped using a standard editbox. they started drawing the text by hand using the ExTextOut() api. this got attacked as well by clever coders (using api hooking or so called detouring). so to my knowledge there is currently no reliable way to read the text in the chatbox programmatically.

when i am at it, some more notes on "PokerStarsNoteSelectorClass". i forgot to mention that the list of players is ordered A-Z. so there is no information to be taken regarding where a player is seated. for a small chance i threw a CB_GETITEMDATA message at the box to see if stars has any data associated with individual items via CB_SETITEMDATA. nope ..that would have been too easy.

On OS X:

The data comes mostly from the hand history files.

Additional data from PokerStars preferences allows one to determine a player's "preferred seat". Once this is know, the locations of the other players can be determined from the most recent hand history file.

Even more additional data comes from the window title.

For Zoom Poker, this is clearly insufficient. We use screen scraping to determine who is it at which table. It is not a perfect solution.

welcome copilot,

yes, OSX is a completely different beast when compared to windows. PT does not have a HUD for zoom there because it is impossible on the unix breed of OSes to get the required data by other means than screen scaping or OCR'ing. just out of curiosity (and if you feel like answering): how do you grab players off the table? i'm in contact with the guys from fpdb and they have plans to generate a hash from player name images and use these hashes as keys to their database. does this sound like a good idea to you?

and then another question: PT (and other) programms seem to have found ways to get the data by other means then scraping that work more reliable. i for one feel it is pretty hard to justify putting mac users to a disadvantage. do you have a comment on this?

to continue, here is the listing required to read out player names from noteboxes on all tables (in pseudo code):

Thanks for posting what you have mme. There are so few people who know this kind of stuff and few if any share their secrets

beat: was hoping SretiCentV was going to spill the beans how hem does it

I'm pretty sure the hand history text is indeed built up in Stars program memory as the hand progresses. I'd love to figure out how to read it, in a convenient open manner.

Many years ago I studied Juk's FPHG 1.0, and re-made it for Stars, not for any actual use but for an experiment - and the client does indeed produce HH files in memory for observed tables. My efforts were poor though and it just produced some of the hands, certainly not all. It also produced "half-hands" but I had no idea if the4y were "in progress" (I couldn't match them up with on screen events) or just more likely bad search techniques! I don't know what I'm doing examining a memory dump, so I didn't - just binary searching it for strings in ahk is the opposite of ideal I'm sure! But we know PT3 does a "memory grabber" for observed hands on normal tables, if you know what you're doing it's prob not too hard to extend that to find the current seated players in the memory. We can guess it's almost certainly "searching" due to updates causing PT4 beta to miss players now and again. We also know this can't work on OSX since it doesn't allow processes to examine the memory of other processes so readily as Windows.

very interesting topic!

Yeah for sure!

Finding the names of seated players without a HH seems even harder (ie: before any hand have been generated - which applies SNGs and "rush" type cash).

I've tried all sorts on Party; from opening up the notes windows (too slow/crap) to using the lobby list (too slow to update) to hooking TextOut() type calls (too hard to figure out which table they were sent to).

After reading mme's post though it gives me hope that there is some way of doing this on Party (the ability to have coloured notes on classic tables would be awesome!).

Juk

not if you knew what my contract looks like!

nice comments ty, back to the challenge.

being able to read player names i went through the client to see if there is any functionality in the client that relies on seats.

first candidate i found is "prefered seat". maybe changing prefered seat triggers some messages one could intercept? nope. i remember some point where seat order changed at runtime when adjusting this setting but this no longer works. seat order remains the same, the setting takes effect next time you start the client. well played stars. again, this would have been too easy.

so back to the tables. double clicking a seat selects a player in the notes box. the same can be triggered via seat context menu selecting "Note". deducing what player is seated on what seat should not be too hard. programmatically double click a seat (via the windows SendInput api), check what player name is selected in the notes box by sending CB_GETCURSEL to the box and query the box for the player name given the index it returns. if CB_GETCURSEL returns CB_ERR you found heros seat because heros name is not in the box. this works for zoom tables and zoom tables only (assuming there is never a zoom table with fewer than N-max players) because for zoom the notes box never contains player names from other tables (at least according to my checks). but this method has some serious downsides:

- you have to know where seats are located in the first place
- you actually have to move the mouse to the position you want to click (stars client has a check for this in place and ignores mouse cklicks when the mouse pointer is not at the click position)
- it may or may not work when windows overlapp and may only work for the current foreground window

i haven't checked in detail because this method is far from ideal for another reason: having to move the mouse around programmatically is enough to rule it out for any serious project. you usually end up accidently flipping windows around and cause all kinds of other unintended damage to your users. user presses mouse button on something, your programm starts moving the mouse around ..boom! here we go ..you may have to answer a call from a pissed off user. lesson learned: never move the mouse around programmatically unless you have a very good reason for doing so and the user is informed in detail about what you are doing.

Its ironic that all of that stuff is allowed but probably the best in that field are kids who love to piss Blizzard off.

Think i v told you everything with this.

it's ironic that this and more is possible. but even more ironic is that legitimate services are put to a disadvantage vs illegitimate services by stars in a systematic way. just thinking that ripping data off the client for data mining on windows is possible while HUDs on mac have to go the OCR path is enough to make me puke.