UCI issues

[Jaap Weidemann]

The engine's only responsibility in this regard is to change its own internal workings when a setoption command is received. When the engine starts up the default values should always be assumed. In other words, it is up to the GUI to remember what values for the various options the user prefers. The GUI should send the changed options with setoption commands when the engine is loaded.

Engines could opt for having their 'default settings' configurable, though, through some ini file, rather than compiled in. If they do, it would only be natura to also provide a button option "Save Settings", which would trigger saving the current settings to the ini file, so that the user can edit the ini file through the GUI engine settings dialog. This way you could even make different sve buttons for sub-sets of the options, e.g. "Save Personality", to only save those settings that affect the playing style.

So I think it is very much a design choice of the engine author.

It is a excellent idea, but unfortunately most GUI's never check if the default values have changed. They build a list of the default options and subsequent values when the engine is installed and changes the values in the list only when the user changes an option value. Only values that differs from the default list built when the engine is installed is sent to the engine when it is initialised. Some GUI's even sends the whole list (as opposed to just the modified options) to the engine every time the engine is initialised. This renders the INI file useless unless the engine prefers the INI settings over its UCI counterparts. Which will in turn render the relevant UCI option(s) useless.

Jaap
http://www.weidchess.com/

I think that should obviously be counted as a GUI bug. (It would for instnce nt work properly at all when you replaced the engine executble by an update that has some different defaults.)

Not if the GUI checks the engine's id name string to establish if the engine version has changed (and if so rebuild the list of options and their values).

For your personality idea to work properly the GUI would have to store the default values (in addition to the user preferred values) and on every engine start compare the defaults to the stored defaults and change the user preferred values to the new default values if it finds that one or more default values changed.

The UCI protocol was designed around the philosophy that the GUI should handle as much as possible (including personalities), thereby decreasing the implementation burden on the engine author at the cost of control.

Jaap
http://www.weidchess.com/

A GUI could remember which settings were changed by the user, and use engine defaults for the settings that were not changed. This seems the proper way to design it.

In other words your idea is for the GUI to prefer option values changed in it to the changed defaults (INI option values). Therefore if the user changes an option value in the GUI and after change the same option's value to something else in the INI file, the INI value is ignored.

It does not matter how you implement it. If you store option values in more than one user editable location, situations will arise where both values will differ from the initial default value. In such a situation you'll have to discard one value in favour of the other. In synchronisation theory this is known as the set reconciliation problem.

This would probably be best solved by timestamp synchronization. Unfortunately this would only be possible with a UCI protocol change. It is therefore not a design choice of the engine author.

I don't think the protocol can be blamed for this. It is not the protocol that forces the GUI to store settings.

From the UCI protocol description:

* option
This command tells the GUI which parameters can be changed in the engine.
This should be sent once at engine startup after the "uci" and the "id" commands
if any parameter can be changed in the engine.
The GUI should parse this and build a dialog for the user to change the settings.

In addition the Shredder GUI, the obvious reference (as it is the implementation by the author of the protocol), stores settings and also stores different personalities of the same engine.

It is all a matter of persitence. If a user makes changes to the default settings, would he want these to persist in later sessions, or would he like to start a new session again with the defaults. What is preferable often depends on the option.

GUI stored personalities solves this problem in a simple way (and is as a result the current standard). No double checking new default values against stored ones and ignoring either GUI stored or INI values if there are conflicts. In other words no user input is ignored. No synchronisation is needed as the data is stored in a single location instead of two editable locations as proposed by you.

With engine-defined options, the GUI cannot know what the most sensible behavior would be. So the responsibility should be with the user, to inform the GUI every time he changes a setting if he want this change to apply permanently, or if it is just a one-time thing. If it is a one-time thing, the GUI should make the choice in favor of the engine defaults (possibly from an engine INI file), if it is persistent, it chooses for the settings stored in its own database.

So if the user changes something in the INI file he should thereafter inform the GUI how to handle the new input. Do you honestly believe that this double editable storage proposal of yours is more user friendly, less time consuming to implement for both engine and GUI authors and less error prone as opposed to simply changing the value in the GUI and telling the GUI store it permanently as a personality if so desired? What extra features does it provide at this cost? At least this is a better idea than the one in your previous post in that no user input is ignored. To avoid confusion I'm referring to this:

A GUI could remember which settings were changed by the user, and use engine defaults for the settings that were not changed. This seems the proper way to design it.

As stated previously, this would have undesired side effect that the INI option is ignored if the value of the same option was changed in the GUI.


I don't know how else to explain this to you save to provide another example:

Suppose you have two mobile phones (with the same phone number) and need everyone's contact details on both devices. Assume that each phone only keeps a backup of the old details when you change someones details in order to simplify synchronisation.

When you change someone's details on one phone and then later synchronise, the following happens:

You compare each persons details on both devices. When there is a difference you accept the details of the phone who's backup is the same than the normal details on the other phone.


But what happens when you changed someone's details on on phone1 from A to X and on phone2 from A to Y?

Both phones' backup copies contains the same value (A). So your in a bit of a pickle. The only solution (as you suggested H.G.) is to prompt the user.

My point is that all this would not be necessary if the user only had one phone. No backup copies of the details is needed. In fact: no synchronisation is needed at all as all the contact details are stored on one phone...

Jaap
http://www.weidchess.com/