about feature option

[Miguel A. Ballicora]

I guess that the engine is supposed to remember the options set by the user. Correct?
All of them?

It is not clear to me the differences between save, button, and reset. Could anybody give me an example to illustrate their spirit?

BTW, how do UCI engines store their modified values by the user? in an ini file?

Miguel

[H.G.Muller]

If you want your engine to remember settings, then indeed, it should save its own options. Which options to save is up to the engine; it would be perfectly OK to have options for people to experiment with, but which you never would want to be default. It would also be perfectly OK to divide your engine's options into groups that can be saved separately, each with its own button.

A button of the type -save is meant for implementing options that save settings. The engine should treat it as a normal button signal. The GUI treats it as special by making sure all other items in the dialog will be flushed to the engine before it sends this button signal. This to make sure that settings that you have changed in the dialog, but not yet confirmed by pressing OK, will participate in the saving. So pressing a -save button is equivalent to pressing OK, and then going back to the dialog to press a normal -button.

The -reset option (which is not implemented yet in WB 4.4.0, but already anchored in the protocol) is meant for options that restore default settings, or otherwise change settings in the engine in the way the GUI cannot know, but should know. To make sure that the GUI won't have stale values for the parameters, it removes all options for that engine when a -reset button is activated. It is upto the engine then to re-build the GUIs option list, by re-sending all option feature commands plus values. The GUI won't know any options that are not re-sent. So it does not merely clear the option values, it cears the existence of the options.

[Teemu Pudas]

BTW, how do UCI engines store their modified values by the user?

I can't think of a UCI engine that does so, except ones that also support Winboard. It's the GUI's job - some GUIs even reset the engine to its old defaults if the user hasn't changed anything.

Which is why you should never set a default value outside the range of a 16-bit signed integer. There are at least two GUIs that will store it wrong.

[H.G.Muller]

The GUI's task is to graphically represent the chess board and provide menus and dialogs for interaction with the user. Not to store stuff. That would be a task for an Engine Manager.

[F. Bluemers]

Engine Manager
What is that supposed to be?
One can imagine a "manager" for just about everything but if you join them you just get a GUI.

[H.G.Muller]

PSWBTM has an engine manager dialog, but I would not call it a GUI. An engine manager is simply a program to maintain a database of engines.

[Miguel A. Ballicora]

If you want your engine to remember settings, then indeed, it should save its own options. Which options to save is up to the engine; it would be perfectly OK to have options for people to experiment with, but which you never would want to be default. It would also be perfectly OK to divide your engine's options into groups that can be saved separately, each with its own button.

A button of the type -save is meant for implementing options that save settings. The engine should treat it as a normal button signal. The GUI treats it as special by making sure all other items in the dialog will be flushed to the engine before it sends this button signal. This to make sure that settings that you have changed in the dialog, but not yet confirmed by pressing OK, will participate in the saving. So pressing a -save button is equivalent to pressing OK, and then going back to the dialog to press a normal -button.

The -reset option (which is not implemented yet in WB 4.4.0, but already anchored in the protocol) is meant for options that restore default settings, or otherwise change settings in the engine in the way the GUI cannot know, but should know. To make sure that the GUI won't have stale values for the parameters, it removes all options for that engine when a -reset button is activated. It is upto the engine then to re-build the GUIs option list, by re-sending all option feature commands plus values. The GUI won't know any options that are not re-sent. So it does not merely clear the option values, it cears the existence of the options.

I think I got it. Everytime OK is pressed, only the parameters modified are sent to the engine. The engine is responsible to keep track of the all of them. I added a button or type "-save" that will save all the parameters in memory a secondary ini file. So, the next time gaviota is opened, the parameters will remain. I did not do that with cores and memory because they are in a different dialog. I guess that will be the desired behavior. Right?

It looks good (picture below), so next Gaviota users won't have to deal with ini files at all, if they do not want it. Still, I have to keep an original ini file in case they want to use Gaviota with other GUIs that do not support this new features.

Now Gaviota supports cores, memory, egtpath, and feature option (saving them). i will try to support nps before I release it.

Miguel