Check out Atomic Chess, our featured variant for November, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Piece Values[Subject Thread] [Add Response]
H. G. Muller wrote on Tue, May 20, 2008 06:39 AM UTC:
First about the potential bug: I am afraid that I need more information to figure out what exactly was the problem. This is not a plain move-generator bug; when I feed the game to to my version of Joker80 here (which is presumably the same as that you are using), it accepts the move without complaints. It would be unconceivable anyway that a move-generator bug in such a common move would not have manifested itself in the many hundreds of games I had it play against other engines. OTOH, Human vs. engine play is virtually untested. Did you at any point of the game use 'undo' (through the WinBoard 'retract move')? It might be that the undo is not correctly implemented, and I would not notice it in engine-engine play. In fact it is very likely to be broken fter setting up a position, as I implemented it by resetting to the opening position and replaying all moves from there. But this won't work after loading a FEN (a feature I added only later). This is indeed something I should fix, but the current work-around would be not to use 'undo'. To make sure what happened, I would have to see the winboard.debug file (which records all communication between engine and GUI, including a lot of debug output from the engine itself). Unfortunately this file is not made by default. You would have to start WinBoard with the command-line option /debug, or press + + after starting WinBoard. And then immediately rename the winboard.debug to something else if a bug manisfests itself, to prevent it from being overwritten when you run WinBoard again. Joker80 also makes a log file 'jokerlog.txt', but this also is overwritten each time you re-run it. If you didn't run Joker80 since the bug, it might help if you sent me that file. Otherwise, I am afraid that there is little I can do at the moment; we would have to wait until the problem occurs again, and examine the recorded debug information. About the piece values: I could make a Joker80 version that reads the piece base values from a file 'joker.ini' at startup. Then you could change them to anything you want to test, without the need to re-compile. Would that satisfy your needs? Note that currently Joker80 is not really able to play CRC, as it only supports normal castling