search

ddugovic / Stockfish

Retired multi-variant fork of popular UCI chess engine; please use Fairy-Stockfish instead
https://github.com/ianfab/Fairy-Stockfish
GNU General Public License v3.0
132 stars 44 forks source link

'info string variant' command #109

Closed HGMuller closed 7 years ago

HGMuller commented 8 years ago

First, congratulations with your Crazyhouse implementation; it seems to be very strong.

I have adapted UCI2WB to support the UCI_Variant option. But I still have a problem with the variants that are not standard variants in CECP, such as kingofthehill and racingkings. For working under WinBoard/XBoard these rely on the CECP mechanism of engine-defined variants, which expects the varint selection (through a 'variant XXX' command) to be answered with a 'setup' command specifying at least the initial position.

The problem is that the 'info string variant' command now emitted by Stockfish comes too late for that, as it comes as a reply to the position-moves command, which normally would only be sent when you want the engine to start thinking. It is however possible that the user wants to first set up a position, e.g. by doing a few moves in EditGame mode, before starting the engine. This cannot be done if the GUI hasnot even a clue how large the board is.

I could of course let UCI2WB send a dummy 'position-moves' command just to evoke the 'info string variant' response, but that seems very ugly and clumsy protocol, and I rather not elevate that to a standard. Currently the CECP 'variant' command makes UCI2WB send a 'setoption name UCI_Variant value chess' plus 'ucinewgame' to the engine, and the (optionally) following 'variant XXX' command a 'setoption name UCI_Variant value XXX' plus 'ucinewgame'. I think it would be best if one of the latter two commands would evoke the 'info string variant' response.

It is also a bit annoying that the 'info string variant' command would come for every move, as it would have to make UCI2WB suppress relaying of all of those except the first. I understand you like to do this as a reminder for debugging, but it would be really helpful to me if this debugging info was somehow distinguishable from the essential variant info in reply to setting the UCI_Variant option at the start of the game. If you want to keep the current behavior, would it be possible to also send a simple "info string fen " in response to 'ucinewgame' or setting of the UCI_Variant option?

HGMuller commented 8 years ago

Sorry, where I wrote "CECP 'variant' command above I meant 'new' command.

ianfab commented 8 years ago

I would prefer this behaviour, too, because it should not send the FEN each time you use a position command. This would, however, require some changes, since we cannot get the FEN from the position object as long as it is not set up, but I think this could easily be solved by adding an array of starting positions.

ianfab commented 8 years ago

I have tried to change it and it seems to work fine now. If @ddugovic agrees with us, I will open a PR as soon as he has decided on the currently open PR.

ddugovic commented 8 years ago
  1. I suppose the existing info response ought to conform to the UCI protocol and only occur after a debug command; which seems reasonable as its purpose is to help with troubleshooting. Apologies to @niklasf as well as it must be equally annoying for fishnet to ignore the info response after each position command.
  2. As long as the UCI_Variant command happens before the position command, I see no harm in adding an (unconditional) info response with the default position in response to the UCI_Variant command.
niklasf commented 8 years ago

I think it's fair to unconditionally respond with info string ... to setoption name UCI_Variant (and I wouldn't mind the position to be reset to the starting position of that variant).

If the sole purpose of info string after position then remains debugging, we could just as well drop it and use the unstandardized d.