tim and otim confusion

[Rohan Padhye]

I am confused about one part of the winboard protocol... It says that whenever the GUI sends the command 'time N' it means this is the clock associated with the engine, and 'otim N' is associated with the opponent. It says nothing of white or black.

It's probably because my engine has no sense or white of black, but im confused. In my engine, the AI will play as soon as it encounters the 'go' command or when the opponent moves (provided force=false). It will play as the next player on move. So it doesn't really know whether it's white or black.

Winboard, confusingly sends the timer commands in two different fashions:

Code: Select all

time N
otim N
usermove MOVE

Code: Select all

time N
otim N
go

Considering white to play before these commands were sent, the first set of commands sets 'time N' for black because that is what winboard thinks the engine is playing and the second set of commands sets 'time N' for white because it wants the engine to GO playing as white.

Now when these time and otim commands are received before either the usermove or go command, how can one figure out which side the time is for?

The only possible solution I can find is to always associate a role for my engine (Black, White, or nobody) so that I can interpret 'time' as clock for the role of the engine... but I want to know if it is possible any other way (or if my conclusions were wrong in any way).

[Rohan Padhye]

Well for now I've just associated one clock with the engine, and every 'time' command that comes in I associate it with that clock variable. I completely ignore the 'otim' command (is knowing how much your opponent has on clock useful in time control strategy?)... This is working fine when using with Winboard because it is decent enough to send 'time' commands before each usermove or 'go'.... But if some GUI sends the 'go' command to make the Engine switch colours without sending a 'time' command first, then the engine will continue using the earlier clock sent to it (even though it was for the opposite colour and it should have paused between moves). This is certainly not the right behaviour, but then again, should one design an engine for such GUIs? Or is sticking to the protocol in its strictest sense safe enough?

[H.G.Muller]

The time command should always represent the time on the engines clock, on which it bases how long it will think for its _next_ move.

The engine might not know that it has changed color when it receives this command, (because it will not know if it will be followed by a usermove or go), but the GUI does know that before it sends it. So the GUI will use the time on the clock of the color that it will make the engine think for with its subsequent command.

I don't think there are any GUIs that would not send you the time and otim before every move you have to make, unless the engine request to suppress it (through a feature command). If they did not, you would have to account the time for both youreself and the opponent since the last such commands (or the initial level). To which color the last received time command applies would have to be judged in the light of the first move produced by the engine after this command, which is apparently the side that the engine is playing, and for which time sends the remaining time.

[Rohan Padhye]

Ahhh, that clears my mind. Thank you.