lucasart wrote: ↑Tue Dec 22, 2020 1:32 amBut this does not solve the parsing problem. You just made it worse by accepting both: CECP v2 accepts "MOVE" and "usermove MOVE", the latter being only allowed if the engine has "feature usermove=1". So you make the engine code yet more complicated, because it has to deal with both.
Are there any actively developped engines that use CECP v2 with usermove ?
It is acceptable for engines to only accept v2 of the protocol. And a GUI should not be considered v2-compliant if it does not support at least the features ping, setboard, usermove and done. So there is no need to program for the possibility that these features are rejected. So there is no need to recognize bare moves when you send feature usermove=1, any more than that you need to implement the legacy 'edit' command if you send feature setboard=1.
I don't really know what other engines do. Of my own engines KingSlayer uses usermove, but Fairy-Max doesn't (and it also doesn't support setboard). It is no big deal to support both usermove and bare moves, btw., and when you run the engine from the command line (e.g. for debugging) it is very handy when you can omit the 'usermove'. If the second character of an input line is not alphabetic, the command is a move.
The important point of my message, though, was that 'force mode' is not a communication phase where a different set of commands (namely moves) applies (like the obsolete 'edit' mode really is: after 'edit' tou can only receive #, c or piece+square commands, until a . puts you back in normal mode). Moves are separate commands, that can arrive in any of the (non-edit) modes. So if the engine supports setboard, it only needs a single command loop, in which it must be able to recognize moves as well as other commands. It is just that after receiving a command, the engine must in principle always check whether it should launch a search, and if so, what type of search. This depends on the player mode, side to move and ponder setting. If the player mode is FORCE, then the engine will never search, irrespective of the stm or ponder setting.
lucasart wrote: ↑Tue Dec 22, 2020 2:07 amAll these are equally valid basetime CECP v2: "5:3", "0:303", "5.05".
Well, 5.05 is probably not OK; in the official CECP spec numbers are always integers. Sub-second base times are still rare even today. That does not hold for increments, though, so an extension of the 'level' command to allow fractions on that would be natural.
But sub-second timing is never recommended when not running on a bare machine; scheduling algorithms of operating systems would introduce a lot of noise, degrading the accuracy of the result. For fast test I developed another method, sometimes refered to as TIN (Time Is Nodes). There exists a feature nps, which allows the GUI to send an 'nps' command to the engine for defining nodes as a unit of time measurement, specifying the equivalence. The engine can then interpret the settings specified in the 'level' command as the equivalent number of nodes. If an engine typically runs at 1Mnps, setting it to 'nps 1' effectively redefines the time unit as micro-seconds. And no high-accuracy timers are needed, and it is completely insensitive to communication or scheduling delays.