This is our first public release of our bot. The executable and associated script can be found here: yan-peter-bot0.3
We plan to post substantial improvements to this bot as they are made. Like collaboration will be appreciated.
If you have any problems please leave a comment.
Update: In light of the dealer bug here’s an updated version of our bot yan-peter-bot-0.3.1
Please provide shared lib also, or static link it.
“error while loading shared libraries: libpoker-eval.so.1: cannot open shared object file: No such file or directory”
Make sure you get the lib properly installed or downloaded. More info is available here:
http://packages.qa.debian.org/p/poker-eval.html
http://pokersource.sourceforge.net/
Here’s the link on the Debian Package Tracking System: http://packages.qa.debian.org/p/poker-eval.html
If you’re interested in using poker-eval in your own development, here’s the project’s website: http://pokersource.sourceforge.net/
There’s a Python version too.
Here is the libpoker-eval.so.1 file we used: libpoker-eval.so.1
You might need to put it in your executable path.
Please let me know if it still doesn’t work.
So, after our team tested play against yours, it seems that your bot has broken the rules of raising. Don’t know why dealer won’t stop you from doing that. The scenario I am talking about: crrrc preflop. you guys raised twice, which in our team’s opinion is illegal — each player is only allowed to raise once, the maximum pot being 140 after both rounds of betting.
So, after our team tested playing against yours, it seems that your bot has violated the rules of raising. Don’t know why dealer won’t stop you from doing that. The scenario I am talking about: crrrc preflop. you guys raised twice, which in our team’s opinion is illegal — each player is only allowed to raise once, the maximum pot being 140 after both rounds of betting.
We find the “bug” also. That should be the problem of the dealer. Or, as we understand it, ‘maxraise’ actually means maximum number of “re-reraises”.
As Ben and I understand it, the maximum number of raises is literally the maximum number of raises — reraising plays no part.
That’s how we initially interpreted it, but the dealer seems to interpret the maxRaises value in the game definition as the number of re-raises. To get a game with a limit of two raises we set maxRaises to 1.
Yes, it looks like there is a dealer bug. The result of raiseIsValid is correct, but if a player tries to raise when a raise is invalid, the dealer allows it.
A quick patch for this is to change line 822 of game.c to return 0 instead of -1. It should be:
This one of the dangers of C – since there is no boolean type, 0 is used as FALSE, but then sometime the wrong value is returned!
(I know some of you were hoping to exploit this in the final tournament, but I will report the problem to them, so it will probably be fixed. For our tournament, I will use a fixed server.)
Starting to feel uneasy about this whole protocol now. Anyway, when we found the isValidAction problem, we interpreted it as a problem with how we are using the API. So instead of patching their codes (we didn’t want to mess up the dealer), we patched our own by using isValidAction(…)<=0
So now we have a (possibly buggy) dealer that does allow two raises, even with maxRaises set to 2.
So yea, if we want to re-fix the dealer and everything so that maxRaises =2 actually does mean two raises in total, the line to fix would be in game.c, raiseIsValid()
if( numRaises( curState ) > game->maxRaises[ curState->round ] ) {
/* ‘>’ was ‘>=’ */
But are we sure we are not misinterpreting the protocol?
no wait, ignore my last comment
Ok, I just re-tested it. It seems like fixing the dealer bug (returning 0 instead of -1) takes care of that problem … in other words, we didn’t have to set maxRaises to 1, we left it to 2.
That is correct. I was changing the game definition file because we weren’t aware of the dealer bug at the time.