Xboard 'move'/'time' command order

[stevenaaus]

Some of the xboard engines play way too fast under Scid vs. PC's tournament, though others are fine.

I used to issue 'move' then 'time'. eg (for one minute games)

Code: Select all

d7d5
time 5692
otim 5898

But perhaps this should be

Code: Select all

time 5692
otim 5898
d7d5

Anyway - It works much better with Olithink.
Can anyone tell me if the later is correct ?

[Ferdy]

Winboard do the later, that is time first before the move.

[Michel]

Sending a move in the xboard protocol is an implicit "go" command. So all parameters for the subsequent search should be set up before sending the move. So yes time and otim should be sent first.

[stevenaaus]

Cheers. That's a big improvement.
Strange that it didn't affect some engines.

[hgm]

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.

[stevenaaus]

I fixed another bug too.

Xboard engines are very helpful - issuing resignations and declaring draws. But they sometimes do so immediately after making a move.

Code: Select all

Engine: move h6h7
Engine: 1-0 {Black resigns}

I hadn't examined this closely before, and it screwed up my control mechanism. (The opposing player is told to make a move, but since the game becomes finished in the meantime, his move is never processed, causing a vwait to hang forever). I think i've this should be fixed now.

[stevenaaus]

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.

UCI of course includes the times on the same line as "go", which is much less ambiguous.

I *do* have a soft spot for the xboard protocol. It's just that it's so damn .... ambiguous and confusing sometimes.

[hgm]

UCI of course includes the times on the same line as "go", which is much less ambiguous.

In case of the times this is true, but it does not solve the other problem. Because the moves and go are still on separate lines. So if there is an illegal move in the position-moves command, the "go ..." command would already have been sent before the engine can complain about the illegal move. Also in UCI there is no acknowledgement of the moves when they are OK, so you would have to force your own by sending "isready" after "position-moves" and wait for the "readyok" before sending "go ..."