michiguel wrote:I agree the protocol should be upgraded in this respect. It is badly needed
This problem was solved long ago. The command specified in the protocol for claiming a draw that only can be claimed after your move is offer draw. This both works in ICS and local mode.
Crafty is simply non-compliant, using a command (1/2-1/2) at a time where the protocol does not allow it and prescribes a different one.
There is no need to extend the protocol; the current protocol handles everything perfectly. Provided engines stick to it, of course. When they violate protocol, anything could happen. This is a general and unavoidable trait of protocols. More explanation in the other thread.
Crafty is actually not "non-compliant". It uses the offer draw exactly as it is supposed to. Once all of that is completed, it does send the "result" command as it is allowed to. The GUI is free to ignore the result, or it can use that and append it to the PGN to have a reason for the result if it is not capable of figuring this result out on its own. I don't depend on the result command to end the game. It is simply information sent to the GUI, _never_ incorrectly, to let it know that Crafty (correctly) believes that the game is over. Crafty will happily continue to play if the GUI ignores this. Ditto for draw claims and offers via the "offer draw" command.
The problem with the current protocol is the timing for the "offer draw". It is likely that an author won't understand the timing issue and think it is perfectly acceptable to send a move and then the offer, when this leaves an ambiguity that can cause problems... I'm perfectly happy with how it is working. After having played millions of games over 15 years on ICC, Crafty works perfectly in that environment. I've made it as adaptable as possible. You don't like the result command it sends? Ignore it. Crafty won't mind. You don't want to offer the opponent draws and keep up with that extra state of "draw offer pending" then don't deal withit. Crafty won't mind. You don't want to deal with the draw claims such as 50 move and repetition? Ignore them. Crafty will happily play on without complaint. I've tried to make it as compatible as possible. Most of the xboard protocol was developed _around_ Crafty, since it was the primary engine running on ICC under xboard, for many years. I wanted the rating of my opponent, then the name of my opponent, etc... and Tim or I added code to deal with each idea that seemed reasonable.
Some simplification and clarification would not be a bad thing.
Well, times have changed, and what you call "compliant" I simply consider imaginative abuse of the protocol.
According to the specs, RESULT commands sent by the engine are supposed to terminate the game, and should not be used if there is the slightest possibility that the game might have to continue. Tim Mann explicitly warns against using it even for accepting draw offers. In all vrsions of WinBoard I have ever seen a RESULT command in local mode always terminates the game.
That you did get away with this in earlier implementations was just luck, but your luck has run out now. Newer GUIs enforce the protocol more strictly, and now you are caught at it.
hgm wrote:Well, times have changed, and what you call "compliant" I simply consider imaginative abuse of the protocol.
According to the specs, RESULT commands sent by the engine are supposed to terminate the game, and should not be used if there is the slightest possibility that the game might have to continue. Tim Mann explicitly warns against using it even for accepting draw offers. In all vrsions of WinBoard I have ever seen a RESULT command in local mode always terminates the game.
That you did get away with this in earlier implementations was just luck, but your luck has run out now. Newer GUIs enforce the protocol more strictly, and now you are caught at it.
I'm not sure what you are talking about. This was fixed a year ago when we had this discussion. The issue is that now I follow FIDE rules and first claim a draw, and then send the move. There is no other safe way to do this, for reasons I have already given. Sending the move and then the draw claim is a good way to lose a game that should be drawn. I don't send the "result" string to claim a draw and try to end the game. I do send it (I think) if I am certain the game is over, although Crafty will continue to play if asked.
hgm wrote:Well, times have changed, and what you call "compliant" I simply consider imaginative abuse of the protocol.
According to the specs, RESULT commands sent by the engine are supposed to terminate the game, and should not be used if there is the slightest possibility that the game might have to continue. Tim Mann explicitly warns against using it even for accepting draw offers. In all vrsions of WinBoard I have ever seen a RESULT command in local mode always terminates the game.
That you did get away with this in earlier implementations was just luck, but your luck has run out now. Newer GUIs enforce the protocol more strictly, and now you are caught at it.
I'm not sure what you are talking about. This was fixed a year ago when we had this discussion. The issue is that now I follow FIDE rules and first claim a draw, and then send the move. There is no other safe way to do this, for reasons I have already given. Sending the move and then the draw claim is a good way to lose a game that should be drawn. I don't send the "result" string to claim a draw and try to end the game. I do send it (I think) if I am certain the game is over, although Crafty will continue to play if asked.
I just checked to confirm, but Crafty no longer sends the "Result" command at all. But it does offer / claim draws via the "offer draw" command.
