Don wrote:Presumably, if a session is not specified it is the same as the previous session, right?
hgm wrote:Don wrote:Or better yet, use the level command for deprecated backward compatibility, but encourage the use of the modern and more flexible alternative (giving it a new name.)
Well, that definitely is a possibility. We could send
session 1 MPS1 TC1 INC1
session 2 MPS2 TC2 INC2
session 3 MPS3 TC3 INC3
...
where session 1 by definition starts with the move to be done next.
Although sending all sessions at the beginning of the game, I still would like to put in the specs that the GUI would have to send a new set of session commands at the start of every new session, if this set would be different from the previously sent set. I.e., it could refrain from resending the last session again, when it repeats, which means that simple time controls would behave exctly the same way as the level command behaves now.
This makes the implementation of engines that feel no need to guard against maliciously designed time controls, such as 40/60min + 1sec/game: they could just use the first session command, and ignore the rest. Or, if they are slightly more paranoic, only use the first two.
On the other hand, there might actually be applications for maliciously designed time controls. So I can imagine that a GUI could be set to intentionally withold the later sessions from the engines, letting them play as if they would be at a classical TC (#moves/#min, repeating), and then suddenly switching to a very fast sudden-death control to force a game decision (possibly taking away any leftover time).
I'm not sure how I would use the "session number"
I don't currently do this, but in Cray Blitz all I needed was
(1) remaining move until next time control (session in this terminology I suppose) and how much time is left on the clock.
(2) how many moves in the next time control period (session) and how much time will I gain?
I used (2) to help me during (1). If I build up some extra time during (1) due to ponder hits or instant moves I might want to use it (or part of it) during the current session, or I might want to save it for the next session, particularly if the next session is "sudden death".
There is a subtle race condition in sending this stuff that can cause some grief, as when we cross a time-control boundary, and a new "level" command comes in, in Crafty I have already updated the clocks for the new time control, set a target time, and started a new search. A new search sets up some things based on the time control, and if a new level command comes in after this point, it is not easy to re-adjust everything.
I'm thinking that my old time code probably needs to go away, and I simply ignore time control boundary adjustments and let the level (or new command) handle this completely. I suppose it is workable to not know the next time control's values until it actually arrives.
Given that, I think the current "level" command works just fine, so long as the GUI sends the information right after the appropriate move is made. In that case, I'd modify the way I do things and remove the code that keeps up with time controls completely, which would be significantly simpler than what I currently am doing. After move 40 (assuming a level 40 N inc) level was used first, the current new level command can set everything needed, and Crafty won't be worrying about reaching move 40 and updating the clock itself, the next level command will do that...