WB time controls (Uri, HGMuller, Hyatt, etc) for ChessGUI

[hgm]

Yes, the latter point is exactly why I think the engines should be told from the very beginning what they can expect. Due to the effect Bob mentions they would most likely not forfeit, but there would be an extremely suboptimal distribution of time in a long game in the case you mention: the 1 min for the rest of the game comes already as an unpleasant surprise, but the worst thing is that it will assume this 1' is for another 40 moves. So if the game lasts more than 80 moves, it only saves a few seconds safety margin for moves 81-infinite, counting on getting new time quota which will in fact not come.

But I don't think the fact that Movei supports it should carry much weight: you are one of the very active developers, and if we decide to make the implementation slightly different from what Movei has now, I am pretty sure you would have implemented it that way even before I would have been able to put it in WinBoard...

I consider it a very bad feature that the user would have to judge (which means most likely: guess) if the engine would be able to handle the extended level command. I really want a protocol that bases it on the engine enabling it, through the 'features'.

To not force incopatibility with engines and GUIs that now do this in an undefined 'wild' way, I think it is better to introduce a feature xlevel=N that can be used next to the wild way. Perhaps it would be better then to change the name of the command itsel in 'xlevel' as well.

[bob]

Well, I tried to google for engines that do support this, and the only engines that I could find that advertized this feature turned out to violate WB protocol to such an extent that they wouldn't work anyway, even if we would implement it the way Uri suggests.

So to know what we are talking about:

Which engines exactly do support this feature, and which of those do it in an acceptable way (requesting it through a features command)?

What Bob says is only true to a limited extent: engines won't lose on time, but they might start distributing time in such a funny way over the game that it results in a certain loss due to being outsearched too much in an extended phase of the game (e.g. facing 10:1 time odds).

I really only said what _I_ do when playing under winboard/xboard. The only thing I consider is time left and increment. Note that I have not seen a real event that only used an increment in the last time control. The "fischer clock" doesn't work like that, it always uses an increment, or else never does. I patterned my "increment handling" after that model.

I have the ability (and always have) to deal with multiple time controls. The old ACM events were always played at 40/120min + either 10 moves in 30 minutes or 20 moves in 60 minutes, and we never used a clock with an increment. At some point we decided to try a sudden death time control in an ACM event, but I already had that because we used to play in human events that had a sudden-death time control and had to support that to have a chance of winning those kinds of games.

My time control command (used in tournaments) is:

time 40/120 20/60 sd/30

which says 40 moves in two hours, then 20 moves in one hour, then game in whatever time is left after adding a final 30 minutes to the current clock time. I personally prefer that kind of time control over the current approach of "level moves time increment" because you have to guess how to allocate your time since there is no clue about how long the game will actually last. Secondary time controls eliminate much of this uncertainty and make it easily for programs to allocate time and remove a little of the "luck factor" from the games...

My only suggestion to your idea was that either there is an increment, or there isn't. Or, as a last resort, there is an increment for each secondary time control as in level moves time inc moves time inc 0 time inc, although I am not aware of any real events that would have "inc" different in each time control segment.

But if you are going to modify this, I would suggest overkill rather than later wishing we had another option. "moves time inc" for each time control covers every possible base.

[bob]

Yes, the latter point is exactly why I think the engines should be told from the very beginning what they can expect. Due to the effect Bob mentions they would most likely not forfeit, but there would be an extremely suboptimal distribution of time in a long game in the case you mention: the 1 min for the rest of the game comes already as an unpleasant surprise, but the worst thing is that it will assume this 1' is for another 40 moves. So if the game lasts more than 80 moves, it only saves a few seconds safety margin for moves 81-infinite, counting on getting new time quota which will in fact not come.

But I don't think the fact that Movei supports it should carry much weight: you are one of the very active developers, and if we decide to make the implementation slightly different from what Movei has now, I am pretty sure you would have implemented it that way even before I would have been able to put it in WinBoard...

I consider it a very bad feature that the user would have to judge (which means most likely: guess) if the engine would be able to handle the extended level command. I really want a protocol that bases it on the engine enabling it, through the 'features'.

To not force incopatibility with engines and GUIs that now do this in an undefined 'wild' way, I think it is better to introduce a feature xlevel=N that can be used next to the wild way. Perhaps it would be better then to change the name of the command itsel in 'xlevel' as well.

This should not be a "catch-22" design decision. I really don't think it is that important what _old_ engines can or can't handle. If they are not being actively developed, I'm not sure there is much point in including them in tournaments... I can't see any reason to hobble current testing because older engines won't support the new idea.

As I said in other such discussions, make this part of winboard protocol 3, and use the feature command to turn it on or off. If both don't support it, then the GUI has to have some option, either not play the game, or make both use protocol 2, or let one run with 2 and the other with 3.

[Matthias Gemuh]

This should not be a "catch-22" design decision. I really don't think it is that important what _old_ engines can or can't handle.

That is how I see it too.

Matthias.