Winboard Forum

When making a move that would result in a repetition, my engine sends "offer draw" to xboard and then sends the move. For example:

offer draw
c8a6

It looks like xboard (I am using 4.7.3) then sends "draw c8a6" to the server, and then the move "c8a6". But the draw command is invalid because the ICC server at least does not allow a move after the "draw" command. draw plus an argument is used to offer a draw in an adjourned game to a specific player. The online docs say:

"If you are about to make a move which will result in the third
repetition of the position, use the "draw" command, and THEN make
your move. Even if your opponent declines your draw offer before
you move, you will still get the draw if your move causes a third
repetition of position."

So ICC wants just "draw" and then the move. It is actually working as expected anyway (game ends in a draw) but the log show the draw command rejected:

719504 <first : # time check interval=15726 elapsed_time=24794 target=28612
719504 <first : 41 52 2479 311933831 Ba6
723341 <first : # terminating, time up
723341 <first : # terminating, time up
723341 <first : # terminating search (controller)
723341 <first : # time check interval=7721 elapsed_time=28632 target=28612
723341 <first : # search done : move = c8-a6
723341 <first : 42 52 2863 353738973 Ba6
723341 <first : # state = 0
723341 <first : # game_end = 0
723341 <first : # in check_pending
723341 <first : # repetition draw
723341 <first : offer draw
>ICS: /
>ICS: draw\015\012
723341 <first : move c8a6
>ICS: /
>ICS: draw
>ICS: c8a6\015\012
>ICS: c8a6\015\012
723448 <first : tellics whisper time=28.63 sec. score=+0.52 depth=42 nps=12.35M cpu=1193.74% pv: Ba6
>ICS: whisper time=28.63 sec. score=+0.52 depth=42 nps=12.35M cpu=1193.74% pv: Ba6
>ICS: \015\012
723449 <first : # in check_pending
723449 <first : # in ponder(), move = c8-a6 predicted reply = (null)
723449 <first : # ponder move = (null)
723449 <first : # out of ponder()
723449 <first : # in check_pending
723449 <first : # ponder failed, exiting ponder loop
<ICS: Sending draw offer.\015\012aics%
ics input 74, castling = 45 45 6 45 45 6
<ICS: You can perhaps use "draw" by itself.\015\012You can say "draw c8a6" while not playing.\015\012aics%
ics input 74, castling = 45 45 6 45 45 6
<ICS: \015\012<12> ------k- ----bpp- b--p---p -NnP---- ----P--- --Bp---P ---N-PP- ------K- W -1 0 0 0 0 11 134\
Gaon ArasanX -1 15 5 14 14 657 816 38 B/c8-a6 (0:29) Ba6 1\015\012{Game 134 (Gaon vs. ArasanX) Game drawn by \
repetition} 1/2-1/2\015\012computer-pool rating adjustment: 2096 --> 2106\015\012aics%
ics input 74, castling = 45 45 6 45 45 6
Parsing board: ------k- ----bpp- b--p---p -NnP---- ----P--- --Bp---P ---N-PP- ------K- W -1 0 0 0 0 11 134 Gao\
n ArasanX -1 15 5 14 14 657 816 38 B/c8-a6 (0:29) Ba6 1

The multiple sending of moves and draw commands is a work-around for annoying differences between ICS, and their overloading of the 'draw' command by using it both for offers and claims. FICS has an atomic draw command for solving the race condition that exists with claiming draws that are claimable only after the move. Without such a command, the draw claim would be rejected (or at least be down-graded to an offer, which might not be accepted) if you send it before the move, and might be pre-empted by an opponent move that destroys the claimability if you send it after the move.

ICC solves this by letting a claimable draw condition automatically accept any draw offer, so that you won't suffer from the down-grade of the claim to an offer. But FICS doesn't do that, and the only way guaranteed to work irrespective of how fast the opponent moves is to use their atomic command that sends draw + move on the same line. So what XBoard does is send three commands:

draw
draw MOVE
MOVE

ICC will reject the "draw MOVE" command, without it having any effect on the game, but because it does interpret the "draw" and the MOVE in its own way, it will grant the draw. FICS will interpret the "draw" as an offer, but then will honor the atomic claim, so that the isolated MOVE will reach it after the game has already finished. It will then be rejected without any effect on the game.

Perhaps not a very elegant solution, but it works on both FICS and ICC (at the expense of drawing an error message), and even on the the public-domain ICS code that has no special provisions for solving the race condition.