TalkChess.com

[H.G.Muller]

Indeed, the latter method is obligatory, as many (most?) WinBoard engines do not look at input at all when they are searching. (And they will be, as soon as they receive the move). So they would in general see the time and otim commands one move too late, making them believe they have more time than they actually have.

This might not hurt them if they take generous safety margin on the move just before the time control, and will probably have no observable effect at all in incremental controls.

That you have to send the times in advance is the reason for this very obscure paragraph in the protocol specs about "clock staying with the engine". What is meant is that when the engine is playing black, and white is to move, and you send

time 30000
otim 20000
go

so that the engine will from now on play white, the 30000 specifies the time for white, and not for black, although the engine received the time command at a time when it was still playing black.

I noticed there is a very grave problem with WB protocol, in connection with the "go" command:

when the engine gets out of force mode (e.g. because until now it was in the GUI book), and you want to set it playing, you can only do that when it has the move. So you first send it the opponent move, then "go"

move g1f4
go

But now when the move was illegal, the engine replies with "Illegal Move", making WInBoard take the move back. But the "go" command has already been sent, and there is no way for WinBoard to take that back! So the engine is now actually searching for the other color than you intended.

I guess it really should use ping before go and wait for the corresponding pong to make sure the preceding move has been successfully processed, before it can safely send "go". But currently waiting for pong is not implemented in WinBoard; it uses ping only as a fence to know to which game received moves belong.

A much better way to handle it would be to use "playother" before the move, but almost no engine supports that.