585
edits
Changes
UCI
,→Contra
It removes several critical engine-decisions that are best made by the engine, not the GUI.
[[H.G.Muller]] wrote on a [[Talkchess]] thread <ref>[http://www.talkchess.com/forum3/viewtopic.php?f=7&t=72019&start=36Re: PGN standard, its improvement and standardization]by [[Pham Hong Nguyen|Nguyen Pham]], [[CCC]], October 14, 2019 » from [[Portable Game Notation]] to [[Protocols]]</ref>
IMO statelessness w.r.t. the game state (including clocks) in UCI was a very bad idea. It is not only that it makes the communication unnecessarily verbose, but w.r.t. clocks there is a real problem: in classical TC the timing info accompanying the 'go' command does not specify how much time will be added after the 'movestogo' have been played. With movestogo=1 and wtime/btime=59000 you could be in a 40moves/hour game, at the brink of receiving another hour for the next 40 moves, in which case it would be wise to completely spend the remaining 59 sec on the upcoming move, as this is already below average. But you could also be in a 40moves/min game, where you got out of book after 39 moves, and receive only 1 new minute for the next 40. Wasting the 59 sec on a single move now effectively reduces your time for the second session by a factor 2, which would be very sub-optimal. The time management in this case should act like you have 1:59 for 41 moves (but be aware of a 'cold-turkey deadline' for the upcoming move). There is no way a UCI engine could know this.
