hgm wrote:Yes, he did, but that is allowed. XBoard should have realized the move belonged to the previous game because it came before the pong.
This problem was reported before, and the code in XBoard handling it seems pretty sick. I am not sure what exactly it is supposed to do (I mean, why would you ever want to undo moves in zippy mode?) So fixing this would probably break other things.
I think you could do perfectly well with ONLY allowing undo when someone physically presses the "back up" button... Otherwise, never send it. If you want to try a test with it, I can run it some on ICC while watching for issues...
Wouldn't bother me to see edit removed. I'd immediately remove it from Crafty. Setboard is much more concise, and is not even needed with normal games anyway...
bob wrote:I think you could do perfectly well with ONLY allowing undo when someone physically presses the "back up" button... Otherwise, never send it. If you want to try a test with it, I can run it some on ICC while watching for issues...
As it stands now, WB will send an undo if one side sends an illegal move such as d2d4 in response to e2e4. (This is handy for debugging move color changes.) Otherwise, WB should send an Illegal Move message.
bob wrote:I think you could do perfectly well with ONLY allowing undo when someone physically presses the "back up" button... Otherwise, never send it. If you want to try a test with it, I can run it some on ICC while watching for issues...
As it stands now, WB will send an undo if one side sends an illegal move such as d2d4 in response to e2e4. (This is handy for debugging move color changes.) Otherwise, WB should send an Illegal Move message.
Question is, what should the engine do after it receives the undo? Automatically make a different move? If it sends an illegal move, it already has enough problems...
bob wrote:Question is, what should the engine do after it receives the undo? Automatically make a different move? If it sends an illegal move, it already has enough problems...
