UCI "go" command and "btime"/"wtime

[Richard Allbert]

Lol...

Well, I'm altering the Clock class right now...

I am guilty of being lazy... I implemented the time managing class to deal with UCI time commands, which (like the game state itself) are easier to implement... no time management as such is needed.

So I has "bent" the class a little for winboard, ending up with something that just about worked (which explains why I also had problems with the depth + tc orthogonal control).

Now I'm making two seperate functions, and will use feature time=0 in future.



Richard

[Richard Allbert]

Implmenting this is giving me a few problems....

Assuming a non 'sd' or 'st' mode.

The protocol says that after every 'new', the engine gets the level command, and sets the clock. Then, for very thinking session, reduces the time on the clock, and adds the increment if applicable. So far ok.

But what happens in the case of 'playother' ?

That means when the game has started, the engine also has to start an opponents' clock? And when the engine is not thinking, and timer for an opponent's clock shoud be running?

That seems a bit complicated.

Time to hit 'ctrl+A' then delete in my clock.h

Regards

Richard

[hgm]

Well, I don't think it is wise to send time=0, because your engine's time measurements might deviate from the GUI's because of communication and scheduling lag. (Note that WinBoard can play engines on a remote machine over a network!). And finally it is the time as registered by the GUI that decides if you forfeit on time, so there is every reason of having the GUI sync your engine's clocks.

WB protocol does not specify, however, when and even if the GUI will do this. WB does it before every move, but the specs don't forbid a GUI to do it after the move, or every second, or whatever.

I never thought about the "playother" stuff, but I guess you are right. In WinBoard protocol the engine can be inone of three states: playing white, playing black, or playing neither (force mode). In force mode the clocks are stopped. In the other two modes, the clock of the side that moves is running.

There is one other reason why it would be good to allow the GUI to send you otim commands when it is prepared to do so: GUIs that implement time odds might try to fool the engine, so that it does not have to be aware that it is playing time odds, by decrementing the otim clock at a different rate, rather then start it at a diffrent time. This is how I implemented time odds in WinBoard.

[Richard Allbert]

So, before I make big changes, there might be a need to understand otim and time afterall!!

Do you know offhand which engines send time=0 ?

If you do this, then you are living from the engine time each game, not the GUI time.

Perhaps time and otim should become part of the protocol again? I've had a look at some OS engines in the last couple of hours, and they all use otim and time.

Thanks for the input,

Richard

PS when is the Feb Online Blitz?
PPS When will you run a permanent engine server for Amateur engines ?