Determining Cards Programmatically
 

From a programming point of view...how do applications determine which cards are dealt to you and which cards are on the board, in real time?

Re: Determining Cards Programmatically
 

Most of the applications read the hands and board after the hand is over, when it is written to a hand history file.

By and large, they read it from a text file that the software creates. I suppose a sophisticated programmer could write a program to recognize the cards in a poker room window, but this is much more difficult, and probably against the TOS of most poker sites.

Re: Determining Cards Programmatically
 

Hence the question. Reading the text file is simply a matter of having the patience to filter out the data...and not difficult, just semi-time consuming to write.

The "bots" out there have no use for "after the fact" analysis. I'm curious how they're reading the cards. I have no designs on writing one myself, but it piques my curiousity as a software developer.

Re: Determining Cards Programmatically
 

Someone else can probably answer this better, but there are a variety of ways. Party seems to write the hand history files in real time, so for those site you can just read the file. Others might use image recognition or try to intercept the actual data that is sent to the poker application.

Re: Determining Cards Programmatically
 

"Image recognition" would be such a ridiculously hokey way of accomplishing it. I was under the impression that hand history files aren't written until after the hand is over.

Intercepting/decoding the data stream is a realistic possibility, but I'm curious how that would be approached...and if there is a certain point where encryption is abandoned, once it has reached the client's machine.

Re: Determining Cards Programmatically
 

[ QUOTE ]
"Image recognition" would be such a ridiculously hokey way of accomplishing it. I was under the impression that hand history files aren't written until after the hand is over.


[/ QUOTE ]

no idea what you mean by "hokey", but it's likely this is the only way about it.

[ QUOTE ]

Intercepting/decoding the data stream is a realistic possibility, but I'm curious how that would be approached...and if there is a certain point where encryption is abandoned, once it has reached the client's machine.

[/ QUOTE ]

If the data stream can be intercepted/decoded that would be a Very Bad Thing. If you find out it's possible please, please, please tell party poker ASAP.

I have no idea what you mean by abandoned encryption...

Re: Determining Cards Programmatically
 

Image recognition is good but stupid.

HH files are written in real time.

Re: Determining Cards Programmatically
 

Hokey as in terrible and extremely prone to problems. An extremely amateurish method for something that has financial implications.

Once the data gets to the machine, encryption isn't necessary in terms of "intercepting" the data. The problem with this is that software could be written in order to transmit hands in real time...which is obviously a big problem.

Re: Determining Cards Programmatically
 

[ QUOTE ]
Image recognition is good but stupid.

HH files are written in real time.

[/ QUOTE ]

Agreed, I don't think grabbing images is "hokey" at all, pretty trivial in fact, given how reliably they are positioned, we have the image files ahead of time etc... but yes, the HH file is written line by line, so that's way simpler to implement.

Re: Determining Cards Programmatically
 

I can't tell you how many times I've had the software screw up and have the block with the player's name positioned somewhere toward the middle. Any system on the lower end as very as RAM/Video card could encounter this type of anomaly quite frequently. It only takes once to lose a significant amount of cash with a bot. If I were writing this...that option would be out of the question.

Re: Determining Cards Programmatically
 

[ QUOTE ]
"Image recognition" would be such a ridiculously hokey way of accomplishing it.


[/ QUOTE ]

A simple pixel color signature would be quite simple to accomplish. A day's work.

[ QUOTE ]

I was under the impression that hand history files aren't written until after the hand is over.


[/ QUOTE ]

Your impression is wrong, surprisingly.

eastbay

Re: Determining Cards Programmatically
 

That's why it was an impression, not a statement of fact. Frankly, I think a system wide filehook that determines when the images were accessed would even be more accurate in the long run, and even that's a bad idea.

Re: Determining Cards Programmatically
 

I think they do it antigrammatically.

Re: Determining Cards Programmatically
 

hand histories are written in real time, they are appended line by line and can be accessed as they are written.

In other words, I can read the hand history that is currently being written, as it is written, line by line, without having to wait for the file to be completed.

All that is there though is the hand history the same as you would see in poker tracker etc... nothing more

One Street at a Time
wdbaker Denver, Co

Re: Determining Cards Programmatically
 

That's should be all you would need. I'll take a look at the exact structure of the files as they are created.

I still can't believe any self-respecting programmer would use pixels to determine the cards. That's like someone using GoTo or SendKeys.

Re: Determining Cards Programmatically
 

Hand histories are written for Party Poker and its skins, but what about other sites? I think the Pacific Poker hand history grabber intercepts the data. If the data was encrypted and no hand history files are written then I think reading them off the screen would be the only way. Whether it's worth it when Party makes it so easy, I don't know.

Re: Determining Cards Programmatically
 

be nice, I use autohotkey and use script like your referring to, although I haven't called myself a programmer yet so I guess i'm safe from your scathing [img]/images/graemlins/grin.gif[/img]

One Street at a Time
wdbaker Denver, Co

Screen Scraping Is The Only Way To Go
 

The premise that you could hack...
The data stream to the Poker Client...
Assumes that the guys who designed it are idiots.

There are many little tricks to make Screen Scraping...
Via simple API calls to get each pixel color...
Very robust.

So example the "busted" graphics you mentioned...
Min/Max window and it's perfect again.

If you have every pixel...
You can absorb 100% of the information a human can...
In absolute real time.

And you can make any response or analysis...
More reliable than a human.

An experienced, careful human...
Will make a significant error every 200-300 actions.
A well designed automated system can do at least as well.

You make a statement like...
And I'm paraphrasing...
"One occasional error and your profit margin is gone".

Nonsense.

My guess would be...
That an error has something like the following breakdown:

(1) in your favor -> 10%
(2) innocuous -> 80%
(3) costly -> 10%

Pixel color pattern matching...
Is the only professional way to go.

Once you've built a pixel by pixel pattern matching engine...
And can simulate human like mouse movement...
Via a custom mouse driver or API or whatever...
You have total control...
(Over any application).

Also, there is no reason...
For Party to give you a real time text hand history.
Most sites do not.

I would expect Party to eliminate it...
And no one will even notice.

Oh yeah...
And it's also a good idea to isolate the Poker Client...
In a "virtual computer" like VMWare (which works great).

All the Spyware can see...
Is a virgin Windows installation running the Poker Client.
(It can't even see the VMWare...
Unless it does complex low level reads of your disk drive).

rm+

[img]/images/graemlins/cool.gif[/img] [img]/images/graemlins/cool.gif[/img] [img]/images/graemlins/cool.gif[/img]

Re: Screen Scraping Is The Only Way To Go
 

I didn't intend to imply that it would necessarily be catastrophic.

I haven't analyzed the Party window with Spy++...has anyone else? I'm curious if you can read the button text directly through the Windows API in order to determine the amount of a raise, etc...assuming you were taking on the ridiculous NL bot task.

Perhaps I'm too much of a purist. To imply that a piece of software reading all of the pixels has the same information a human being has, is obviously correct...but to assume that a computer has the same interpretation in all circumstances, is not. Human beings have the ability to decipher things that are familiar, in completely different formats. A simple example being, if the buttons were moved to the top, they're still there...but software is looking for them in a different place. If the cards were displayed completely reversed, humans would still instantly recognize the card...not so for software.

All I'm saying is that, from a commercial software programmer's point of view, I certainly wouldn't feel comfortable leaving my house while a bot that's based on pixel mapping is playing hands on my bankroll.

Re: Determining Cards Programmatically
 

[ QUOTE ]
That's should be all you would need. I'll take a look at the exact structure of the files as they are created.

[/ QUOTE ]

And this is all strictly academic curiosity, of course, that you would retain this much interest over several days and "take a look at the files for their structure."

Uh huh.

eastbay

Re: Screen Scraping Is The Only Way To Go
 

[ QUOTE ]
Pixel color pattern matching...
Is the only professional way to go.


[/ QUOTE ]

Agreed. Not all sites write HH line by line (for example, UB does not, you can only get history after the hand). If Party does it line by line now, they can easily change it at any time.

Intercepting data stream after it's decrypted by the client is interesting but most likely much harder to do than pixel matching, and every site does it differently, so it's starting from scratch if you want to do more than one.

Pixel matching is the only way to go, and not really hard.

Re: Determining Cards Programmatically
 

I've seen the files, certainly...I never denied that. I took a look at them long before I'd ever even seen PokerTracker. I'm merely curious how they're built in real time. Your not-so-subtle accusations are standing on pretty feeble legs if you actually read this entire thread.

Just because I have an interest in how something works, doesn't mean that I have any designs on actually attempting to construct it. Such is the bane of a computer programmer/logician. Everything becomes a "How would I do that?" proposition. I can assure you, I have no desire/intention of creating a PokerBot. Purely an extended exercise in the hypothetical.

Re: Screen Scraping Is The Only Way To Go
 

[ QUOTE ]

I haven't analyzed the Party window with Spy++...has anyone else? I'm curious if you can read the button text directly through the Windows API

[/ QUOTE ]

Yes I have...
But I've been using Winspector...
Which is considered by many to be better than Spy++



[/ QUOTE ] You Can Get Winspector Here

You can read all the Party Client controls...
Like SysListView32, etc... but not directly.
You have to tap into the Client's Virtual Ram...
And you're also bombing custom controls with external messages.
This is probably detectable... not to mention complicated.

Screen scrapping is a lot of initial boring pixel level work...
But it can be robust... and it's the way to go.

[ QUOTE ]

The buttons were moved to the top...


[/ QUOTE ]

You don't care where the buttons are...
You are scanning for their location continously.
If the Bot gets confused...
It just shuts down... and buzzes the operator...
Who then takes over.

Same thing with the "Bot Detector" ID boxes.
Bot sees it... buzz...
Man takes over.

[ QUOTE ]

All I'm saying is that, from a commercial software programmer's point of view, I certainly wouldn't feel comfortable leaving my house while a bot that's based on pixel mapping is playing hands on my bankroll.

[/ QUOTE ]

I'm a professional trader...
And Automated Trading Systems are ubiquitous and legal.
People make ** million dollar trades ** using ATS...
And you're worried about Party $33s.

Also..
The "run a Bot all nite and wake up to profits" line...
Is an oversimplification designed to discredit automation.

In reality...
One would build Bots...
That would relieve you of routine play...
And leave the most complex 20% to you.

You would run it like a trading operation...
Where an ATS is manned by a professional trader.

Say you play 50 33s/day...
But you only have to play 20% of the time...
And have real-time equity and ICM info on hand...
That's 6 hours... like a normal workday.
Seems doable.

[ QUOTE ]

assuming you were taking on the ridiculous NL bot task


[/ QUOTE ]

Well...
The Poker Academy NL AveryBot was done by Brian Williams.

He's an outsider...
But it was good enough that U of A included it.

Here's Brian's Web Site

I'll bet Brian's best Bots...
Can beat the 11s, 22s, and 33s.

I've even figured out a way...
To "reverse engineer" the AveryBot and plug it into Party...
** Without infringing on anyone's copyright. **

It's just that it's 100s of hours of work...
And I have a full time trading business.

This is my new hobby.
Best of luck to everyone...

rm+

[img]/images/graemlins/cool.gif[/img] [img]/images/graemlins/cool.gif[/img] [img]/images/graemlins/cool.gif[/img]

Re: Determining Cards Programmatically
 

I advise giving up on your quest to write a bot for Party which I have done and wasted 4 months of my time.

Actually, I got my bot up and running thinking I could sit back and rake in the dough. What happened? Party somehow detected my software usage and closed my account. This sucks!!!

Just don't want you to go through the same odeal.

LYD Meltdown
 

Some guy making statements like...
"intercepting/decoding the data stream is a realistic possibility"...

And comparing sophisticated asynchronous pixel level screen scraping...
To poor programming style using GOTOs...

** Has no idea what he is talking about **.

And you're speculating rather badly about building a Poker Bot...
Then claiming some kind of esoteric intellectual curiousity.

You're credibility is shot on all fronts.

rm+

[img]/images/graemlins/cool.gif[/img] [img]/images/graemlins/cool.gif[/img] [img]/images/graemlins/cool.gif[/img]

Re: LYD Meltdown
 

Couldnt you use a program to detect what image files are being accessed by the party client? When you get your hole cards, two image files have to be loaded into the client, 3 for flop, turn, 1 river. That was the first thing that came to mind, not sure if such a program exists though to make that possible.

Re: LYD Meltdown
 

[ QUOTE ]
Couldnt you use a program to detect what image files are being accessed by the party client? When you get your hole cards, two image files have to be loaded into the client, 3 for flop, turn, 1 river. That was the first thing that came to mind, not sure if such a program exists though to make that possible.

[/ QUOTE ]

Not that I support the idea of creating a bot (I don't), but this seems like the best idea so far. Probably some arcane API call.

Re: LYD Meltdown
 

No idea if they are or not but this won't work if the images are cached after loading.

Re: Determining Cards Programmatically
 

[ QUOTE ]
hand histories are written in real time, they are appended line by line and can be accessed as they are written.

In other words, I can read the hand history that is currently being written, as it is written, line by line, without having to wait for the file to be completed.

All that is there though is the hand history the same as you would see in poker tracker etc... nothing more

One Street at a Time
wdbaker Denver, Co

[/ QUOTE ]

Why are you guys still working on this, its all ready been done as explained above, that's how they do it. Realtime as the file is written, as soon as I see my cards on the table I also see them as written to the file...

Don't need to screen scrape at least for Party skins

One Street at a Time
wdbaker Denver, Co

Re: Determining Cards Programmatically
 

[ QUOTE ]
That's why it was an impression, not a statement of fact. Frankly, I think a system wide filehook that determines when the images were accessed would even be more accurate in the long run, and even that's a bad idea.

[/ QUOTE ]

It's not just a bad idea, it's a terrible idea due to the fact there *will* be collisions with multiple windows. Assuming realtime hand histories aren't available the best is to "scrape" window data and do a very easy pattern recognition against known card images, that way you know what came from where.

Re: Determining Cards Programmatically
 

[ QUOTE ]

In other words, I can read the hand history that is currently being written, as it is written, line by line, without having to wait for the file to be completed.


[/ QUOTE ]

Actually you can read the Hand History file BEFORE it is written. PP keeps a temp HHF in it's root directory that is open as long as you are at a table and is an aggragate of all the hands at the table just like the actual HHF that is written to the HandHistory directory. A good developer could write an IFS device driver to monitor the writes to the file(s). The device driver would have access to the data before it is written to the file and could parse the data in real time. From Microsoft "A file system filter driver can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, filter can mean log, observe, modify, or even prevent. Typical applications for file system filter drivers include antivirus, encryption, replication, and hierarchical storage management products." ....AND real time poker analysis.

Driver's are not easy to write and require an experienced driver developer. I'm an experienced developer but have never written a device driver. Nonetheless, I'm thinking of giving it a whirl.