UCI Protocol

[dbxuau]

Why is there no possible way to recall current engine parameters. We can set them with setname option value etc but there is no way to read out what the settings are. Did I miss the technicality?

[elcabesa]

I don't think it's possible

[ZirconiumX]

Why is there no possible way to recall current engine parameters. We can set them with setname option value etc but there is no way to read out what the settings are. Did I miss the technicality?

In UCI, everything that can be delegated to the GUI is delegated to the GUI. So the GUI's supposed to remember what it set everything to.

Matthew:out

[Aleks Peshkov]

My program displays current settings in response to 'uci' command.
I thought it was obvious implementation.

[lucasart]

My program displays current settings in response to 'uci' command.
I thought it was obvious implementation.

me too.

[mjlef]

Why is there no possible way to recall current engine parameters. We can set them with setname option value etc but there is no way to read out what the settings are. Did I miss the technicality?

Sure you can. Just send the engine the "uci" command again and it will display the current parameter names, values and allowed ranges.

[Daniel Mehrmann]

I don't understand your problem. First you sending all your paramater to the GUI after the "UCI" keyword.
After that the GUI will send you each single parameter change if the user or the GUI change something. So, you know always each state of your options.

[dbxuau]

Take stockfish for example, i do a "setoption name Hash value 1024". I then query "uci". It responds with default values. There is no confirmation nor response to my input at all. Is this inherent only to stockfish?

[hgm]

The UCI specs state that "uci" will only be sent once, at engine startup. So in principle engines can do whatever they want when the receive it a second time, without violating the specs. There actually is a vague phrase in the UCI specs that you should ignore commands that are not supposed to come. This is likely only intended for spurious 'stop' commands (which cannot be avoided due to a race condition, where the engine can spontaneously produce a move just when the user presses 'move now' in the GUI).

As other posters remarked, there should never be any reason to read out the current settings. The engine reports its initial (default) settings, and you know which setoption commands you have sent it since then.

Code: Select all

* uci
	tell engine to use the uci (universal chess interface),
	this will be send once as a first command after program boot
	to tell the engine to switch to uci mode.
	After receiving the uci command the engine must identify itself with the "id" command
	and sent the "option" commands to tell the GUI which engine settings the engine supports if any.
	After that the engine should sent "uciok" to acknowledge the uci mode.
	If no uciok is sent within a certain time period, the engine task will be killed by the GUI.

Code: Select all

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is
  not calculating, it should also just ignore it.

[mcostalba]

Take stockfish for example, i do a "setoption name Hash value 1024". I then query "uci". It responds with default values. There is no confirmation nor response to my input at all. Is this inherent only to stockfish?

It is inherent to UCI protocl

http://wbec-ridderkerk.nl/html/UCIProtocol.html

Maybe reading it would help (it takes 10 minutes).

Changing the semantic of uci command (as any other command) according to the number of times it is sent is tricky and ugly.

The correct solution (like it or not) is the intended one: it is up to the GUI to keep track of current parameters values.