Evert wrote:I get that it's annoying (I don't like having to unwind my entire movestack just to add one at the end either), but ultimately in terms of time spent on it, this is miniscule, so there is no good reason I can see to not do the simple thing and just unwind back to the starting position and walking down the move list.
Code-wise it is not a big deal. You would only repeatedly call code you would execute once otherwise (Setup() + MakeMove()). In fact all my engines (which are WB) contain a sort of WB-to-UCI converter in their protocol driver, used for implementing 'undo' and 'remove': these set up the board again, and then play all moves that were not taken back, like it was loading a UCI position description.
And yes, of course it is annoying. UCI is annoying. It was designed to be annoying. By using it you
choose to be annoyed. If you don't want to be annoyed, don't use it! Otherwise, just 'go with the flow', and bear it!
But it also leaves the loop hole that the engine must deal with it if it doesn't, making it optional in practice for the GUI to send it or not.
This of course is a very bad thing about the UCI specs. This really was a protocol change, but there was no mechanism like the feature time-out in WB protocol for the GUI and engine to negociate which version of the protocol they are going to use. The proper way to have done it was to let engines send an "option name UCI_ProtocolVersion type spin min 1 max 2" to let the GUI know they are v2 compliant or v2 dependent ('min 2'). A v2-compliant GUI could then have set the option, and engines that would be v2-dependent could elect to exit when they receive 'isready' without the option being set.
This is exactly the sort of exchange that Ferdy wanted through the GUI-id command, but in a more general (GUI-blind) way.