UCI protocol for chess variants

[hgm]

Note that in fact this option UCI_Chess960 is a bit superfluous, because it can be deduced from the FEN whether it's a Chess960 position or not.

Indeed, I remarked upon that too. It seems the option is more a kludge to let the GUI know that the engine is Chess960-capable. (UCI_about is another such 'one-way option'.)

Does this mean that a piece drop will be written as "N*f6"? I suggest the common notation "N@f6", why another notation style?

The other notation style is how it is done in USI. But I see no compelling reason to use that more widely. In USI you would also write N*6f, and as far as I am concerned this should simply be part of the 'alpha-rank' notation. The move notation in USI is based on PSN, and for other games we should simply use the more common '@' as drop indicator.

[Ferdy]

Would be great if an engine knows what gui it is run to too.
Something like after receiving the uciok from engine, the gui will
send,

Code: Select all

id guiname ZZZ
id guiversion YYY

I disagree - it shouldn't matter to the engine what GUI it runs on, as long as the GUI (and the engine) follow the protocol correctly.

With this possibility if the gui does not send ucinewgame command at appropriate time, and if that command is critical for the engine to function properly,

But the UCI spec says "ucinewgame" is optional, so if the engine requires it, it's buggy, isn't it?

Yes if both follows there would be no problem.
Take a look of a certain gui, my engine supports UCI_Opponent to calculate automatic repetition score, and others, but "name" is missing in the command.

Code: Select all

292923 >first : setoption UCI_Opponent value none 1900 computer Engine1

Regarding ucinewgame.

* ucinewgame
this is sent to the engine when the next search (started with "position" and "go") will be from
a different game. This can be a new game the engine should play or a new game it should analyse but
also the next position from a testsuite with positions only.
If the GUI hasn't sent a "ucinewgame" before the first "position" command, the engine shouldn't
expect any further ucinewgame commands as the GUI is probably not supporting the ucinewgame command.
So the engine should not rely on this command even though all new GUIs should support it.
As the engine's reaction to "ucinewgame" can take some time the GUI should always send "isready"
after "ucinewgame" to wait for the engine to finish its operation.

See the bolded part, the protocol has implied that it should be supported for new gui, perhaps new version of gui. The missing forceful word should not be made as an excuse not to support such command.
I understand that the engine should adjust, but where did it say optional?

[Matthias Gemuh]

You tell the GUI (by enabling options in GUI) once at engine installation everything the engine is able to do.
The engine's UCI options may be set before each tournament, if necessary.

Does it matter whether I present my options as a combo-box, or should I send the variants as a series of checkboxes?

I can of course do both for maximum compatibility.

GUI tells user what it supports. User selects from that list what engine suppots.

[hgm]

See the bolded part, the protocol has implied that it should be supported for new gui, perhaps new version of gui. The missing forceful word should not be made as an excuse not to support such command.
I understand that the engine should adjust, but where did it say optional?

Well, it says "the engine should not rely on it", which makes engines that do not work properly if it is omitted at fault.

I must say I don't see why this command would be useful to the engine anyway, let alone how an engine could fail to work properly if it was omitted. It seems to me that when you get a position spec as FEN + moves, and are asked to provide a move for it, you wouldn't do anything different when that position is from a different game than when it is from the same game.

Is this really to encourage implementations that ignore the position command and only look at the last move of the moves list, to blindly assume they can play this move from the previous position they searched? I don't think this can work anyway, because the specs even with UCI newgame would allow a GUI to randomly pick a different position from before the last irreversible move on every move of the game, and send the FEN for that, and only the moves coming after it. (But I guess you could only take a peek at the move number field of the FEN and the number of moves in the list to conclude how many moves were added, and only parse those moves and apply them to the position you searched on the previous move.)

It seems that only when you do crazy things like that you would be relying on the move being from the same game.

It is poorly defined anyway what 'same game' means in the face of takebacks. If I allow the user to take back his last two moves (stripping off 4 ply), would we still be in the same game?

[Ferdy]

When the gui sent position fen1 e2e4 e7e5 g1f3 and let me search the position I will remember that fen1 + those moves + the best move that I searched say g8f6, I would expect the gui to send position fen1 e2e4 e7e5 g1f3 g8f6 + b1c3 for example, all I have to do is verify that last move b1c3, if that last move is legal based on my internal board, all is fine, but if that last move is not legal, I have to reset my internal board. There is a situation where the moves will reach 100+ plies in a game, I just check the last move sent by the gui, I usually get a legal move when playing games. But for analysis mode or infinite mode, expect the gui to send different position fens + moves in this case I will re-setup the position and the moves sent if there is.
I remembered a gui just sent position startpos in the beginning, no ucinewgame, but this is not a problem since we are at the beginning, then position startpos g1f3 g8f6 m1 m2 ... mn, n=120, no problem too since I just look at the last move sent and update my move history. Then suddenly you receive, position startpos e2e4 from the gui, no uci newgame was received, so now I have to check that my history ply was 120 and now I receive only 1 move or ply, this would mean that I am in a new game. In this case I will reset my internal board. But it could be easier for me if that gui sent ucinewgame. Let me ask is that really difficult to send ucinewgame command to each engine before the start of a new game to continue the tournament?

[Evert]

When the gui sent position fen1 e2e4 e7e5 g1f3 and let me search the position I will remember that fen1 + those moves + the best move that I searched say g8f6, I would expect the gui to send position fen1 e2e4 e7e5 g1f3 g8f6 + b1c3 for example, all I have to do is verify that last move b1c3, if that last move is legal based on my internal board, all is fine, but if that last move is not legal, I have to reset my internal board.

That seems awfully fragile, and there is nothing in the UCI spec that says that this is a safe or reasonable assumption to make. What if you're playing a human who just backed up a few moves and played a move that would have been legal in your current position as well?

There is a situation where the moves will reach 100+ plies in a game, I just check the last move sent by the gui, I usually get a legal move when playing games.

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.

But it could be easier for me if that gui sent ucinewgame. Let me ask is that really difficult to send ucinewgame command to each engine before the start of a new game to continue the tournament?

Well, clearly it would be better if it did send it. The standard (strongly) recommends 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.

[hgm]

When the gui sent position fen1 e2e4 e7e5 g1f3 and let me search the position I will remember that fen1 + those moves + the best move that I searched say g8f6, I would expect the gui to send position fen1 e2e4 e7e5 g1f3 g8f6 + b1c3 for example,

But that is not a safe expectation. The GUI could send you fen1 e2e4 e7e5 g1f3 g8f6 + b1c3 f8c5 f1c4 because the user switched to Edit Game to force a move for the engine. (Or, more common, the GUI could have had a book hit, and played that on behalf of the engine.)

all I have to do is verify that last move b1c3, if that last move is legal based on my internal board, all is fine, but if that last move is not legal, I have to reset my internal board.

Well, that the move is legal does not imply the position is the same. You cannot just only check the last move, as more moves might be added because of book hits. You can also not just count moves, and add the extra ones, because a the GUI could also send fen3 g1f3 g8f6 b1c3 f8c5 f1c4, which is only one move more, but actually 3 new ones, because the fen starts at a later stage of the game. Of course no GUI will do this in practice, but it is allowed, and to be fully UCI compliant rather than only understanding a certain GUI-specific subset of UCI, it would have to be able to handle this. Ucinewgame would not solve these problems.

[Ferdy]

What if you're playing a human who just backed up a few moves and played a move that would have been legal in your current position as well?

Can you give an example with moves? and commands from gui?

[Ferdy]

But that is not a safe expectation. The GUI could send you fen1 e2e4 e7e5 g1f3 g8f6 + b1c3 f8c5 f1c4 because the user switched to Edit Game to force a move for the engine. (Or, more common, the GUI could have had a book hit, and played that on behalf of the engine.)

I encountered this book moves are added by gui, the moves sent by gui is more than what I have in the history, in this case I will re-setup.

Of course no GUI will do this in practice,

I actually depended on this, that the designer is also doing some sensible things.

[hgm]

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.