Winboard Forum

Hi
While trying to make my engine fully complaint with cutechess-cli I had to make many modifications on winboard protocol implementation.
I have finally managed to avoid all the problems like resignation, repetition and 50-move draws, sending "feature done 0"
while loading egbbs etc... which none of them gave me problems at least in Winboard itself. I am still not clear about draw claims even if i can do test
games with cutechess-cli with no problems now. However, there are still rarely occurring repetition draw problems in Arena with draw claims, which i always
thought were the GUI's problem but I don't think that anymore. I searched for that in CCC and found very loooooonnnnng debates. I am tired and can't go through
all that so i would really really appreciate it if someone clearly summarizes me what the consensus is for the current protocol, especially on the order of move and
draw claims. If there is none, what is the best recommended practice?
Thanks

In local play the engine can use the 1/2-1/2 command to claim a draw even after your move (when it is this move that causes the repetition). In ICS play this might not work, because the ICS is not safeguarded against your opponent throwing in a quick move between when you sent your move and when you sent the claim, so a 1/2-1/2 claim after your move might be refused by the ICS, in which case you have to play on.

This can be avoided by sending "offer draw" to WinBoard just before your drawing move. The ICS (who makes no distinction between draw offers and draw claims, both are done through the same command) will then treat the bending offer as a claim when a repeat or 50-move position ocurs after your move.

So the safe way to do this is first send "offer draw", then your drawing move, and then "1/2-1/2". This works on all WinBoard versions in all modes.

Thanks HG. So i will do the following

i) For 3-fold repetition and 50-move rule draws, I will send [ "offer draw" + move + 1/2-1/2 { Reason for draw} ]

ii) For resignation , I used to do [move + resign] before but i changed it to [resign] only without the move. The first one apparently gives problems
with cutechess-cli

iii) For mates i will do the regular [move + {Reason}] . I think that the GUI will never let the engine to search on a won/lost position, but I will do
the check before and after making a search as a precaution.

As to (i), this is the prescription to claim av draw that materializes only after your move. For a draw that occurs already because of the move of your opponent you can always immediately clain through 1/2-1/2, as there is nomway the opponent could surprise you by a quick move if it is no longer his turn.

Other interfaces (including WinBoard)nwill also have problems if you do move+resign. This because the move is passed on to the opponent immediately, which sets him thinking. (The GUI is not clairvoyant and does not know that you will follow up the move with a resign, and it is not going to wait for something that might not come.) Most engines cannot be interrupted then before they move, and engines that do not support ping then give the move when WinBoard has already started a new game (if you use match mode), and might forfeit one of the engines later for an illegal move. At best it makes that you have to wait for an unnecessary move.

At to (iii), you never know; people can play a GUI without mate detection, and then if you play an engine that doesn't claim, you can get the move in a (stale)mated position. And if you don't claim either, you might forfeit on time.

We're trying to implement the Winboard protocol in Cute Chess (+ cli) as perfectly as possible, so if you want to be compatible with it, it's best to just obey the protocol. HGM's method for claiming draws works (and I prefer it also), although Cute Chess doesn't recognize the "offer draw" command yet.

ii) For resignation , I used to do [move + resign] before but i changed it to [resign] only without the move. The first one apparently gives problems
with cutechess-cli

Resignation without the move is definitely the way to go, but cutechess-cli should handle resignations on opponent's time as well. What kind of problems did you encounter?

Hi Illari
Thank you for giving us such a great tool. I really needed a tool for background testing at fast time controls.
The problems that I mentioned are definitely not a problem of cutechess-cli but the laziness of us authors not to follow
the protocol strictly. So my comments are to be taken with a heavy grain of salt Ok to the issues I had

Test is done at 40/5 on nunn.pgn on two scorpio versions

a) If the game is finished due to resignation from one of the scorpio's with [move + "resign"] , cutechess gets stuck. It doesn't assign a time loss to one of the
engines (as it did in (b) below). I see in the log file that , the other scorpio engine was searching while it receives the result.

b) When I get a "protover" command, I first send "feature done = 0" before loading egbbs as that might take some time and then "feature done=1".
With that scorpio always loses the first game on time, and cutechess chess moves on with the next game.Moving the "feature done = 0" from the
"protover" handling code to the very beginning of main solved the problem.

I have switched to HG's suggestions now.

regards,
Daniel