cs6501: PoKER

Discussion (15) ¬

1. 
   Weikeng Qin

   6 March 2011 at 4:27 pm | #

   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”
2. 
   Yan Huang

   6 March 2011 at 6:48 pm | #

   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/
3. 
   Peter_C

   6 March 2011 at 7:33 pm | #

   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.
4. 
   Yan Huang

   7 March 2011 at 5:30 pm | #

   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.
5. 
   Yuchen Zhou

   9 March 2011 at 2:21 am | #

   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.
6. 
   Yuchen Zhou

   9 March 2011 at 2:22 am | #

   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.
7. 
   Yan Huang

   9 March 2011 at 3:51 am | #

   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”.
8. 
   Ben K

   9 March 2011 at 9:28 pm | #

   As Ben and I understand it, the maximum number of raises is literally the maximum number of raises — reraising plays no part.
9. 
   Peter_C

   9 March 2011 at 9:48 pm | #

   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.
10. 
    David Evans

    9 March 2011 at 10:54 pm | #

    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:

    
      if( action->type == raise ) {
        // fprintf(stderr, "Chacking raise...\n");
        if( !raiseIsValid( game, curState, &min, &max ) ) {
          /* there are no valid raise sizes */
    
          return 0; // was -1
        }
    

    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.)
11. 
    Samee

    10 March 2011 at 2:12 pm | #

    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.
12. 
    Samee

    10 March 2011 at 2:22 pm | #

    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?
13. 
    Samee

    10 March 2011 at 2:26 pm | #

    no wait, ignore my last comment
14. 
    samee

    10 March 2011 at 3:30 pm | #

    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.
15. 
    Peter_C

    10 March 2011 at 4:19 pm | #

    That is correct. I was changing the game definition file because we weren’t aware of the dealer bug at the time.