Onno Garms wrote:What I am missing is:
-
complete information about time control. UCI is blind for what happens after movestogo are played. Try a game with 1 hour for 20 moves and 1 second for the rest of the game
That sounds good to me (although for most
usual time controls the current information seems sufficient for reasonable time management).
Onno Garms wrote:- command to set average time per move. Even the shredder GUI has a feature to set this (set time per move and do not set "exact time"), but it cannot be passed to UCI directly. "exact time" is passed as movetime, but without exact time, the Shredder GUI multiplies the time by 60 and sends 60 movestogo. The latter is a dirty workaround and does not work for all engines.
I wouldn't know how to implement this in an engine: How am I to know what the average per move time is going to be when I don't know how difficult the future move decisions are going to be?
On the other hand, if the average move time is only supposed to be correct
a posteriori, the GUI could already handle that under the present specification by pretending to the engine that it has to survive for 5 moves with e.g. 5*[average move time] time and adjusting this interval depending on the question whether the engine has been using too much or too little time. As this is a rather imprecise job, I would prefer it to be done by the GUI instead of the engine.
Some improvements I would like are:
- allow the engine to
set its own options with "set option ..." (then it could e.g. offer some personality presets which are like macros for changing several other options)
- add support for crazyhouse/bughouse fen strings (I believe it is called BFEN); perhaps X-FEN is more important in general.