Determining Cards Programmatically

LetYouDown · #1 07-12-2005, 04:44 PM

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?

OrianasDaad · #2 07-12-2005, 05:12 PM

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.

LetYouDown · #3 07-12-2005, 05:17 PM

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.

MiguelSanchez · #4 07-12-2005, 05:17 PM

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.

LetYouDown · #5 07-12-2005, 05:20 PM

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

jba · #6 07-12-2005, 05:23 PM

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

baronzeus · #7 07-12-2005, 05:42 PM

Image recognition is good but stupid.

HH files are written in real time.

LetYouDown · #8 07-12-2005, 06:09 PM

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.

TheTROLL · #9 07-12-2005, 06:16 PM

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

LetYouDown · #10 07-12-2005, 08:23 PM

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.