Can anyone test this

[F. Bluemers]

WinBoard does not keep settings of engines. The engine is responsible for remembering its own settings. This seems the best way to do it, as only the engine knows what the options actually mean, and thus can make a distinction between options that it wants to allow the user to change the default for, and options that it considers 'volatile', which should always start at the 'factory setting'.

Engines that want to allow changing their defaults (i.e. the values they start with next time you invoke it) should implement a SaveSettings button option; WB protocol defines a special type of button for this (called -save in stead of the normal -button) that causes the contents of the dialog to be flushed to the engine before sending it the button signal (in case there were still changes that were not OK'ed in the dialog). The engine could then update its own ini file according to this. An engine could even define several kind of -save buttons, e.g. one for saving only harmless preferences, such as the name of a log file, and one to save 'life-threatening' options like piece values.

For UCI engines of course Polyglot would be responsible for saving the option settings in the polyglot.ini file. (Or in a custom polyglot.ini file, the name of which can be chosen by the user through a -string option.)

Of course the settings cannot only be changed from the menu, but also from the command line, to allow tournment managers like PSWBTM to alter them in accordance to information stored in their engine database. The /firstOptions and /secondOptions are provided to pass the list of (non-default) option settings you want for the first and second engine.

Thanks for clarifying that the wb engines should handle the saving of the settings.
Wrt uci engines ,it would be better if they would adopt to the newer wb protocol.
No one would need to use polyglot

Of couse polyglot shouldn't save any settings at all.
Users can edit and use different ini-files.
One can even use a tool like polyglotGUI
http://es.geocities.com/winboard_chess/
Best
Fonzy

[hgm]

Actually the fact that people have to edit polyglot.ini files is the most-frequently given reason why people refuse to use Polyglot, and thus WinBoard. They do not care how much more stable it is, what it can do more, etc. "I would have to edit .ini files with a text edtor." End of story...

This can only be solved offering them a way to edit the ini files with a graphical 'editor' like PolyglotGUI or the WinBoard dialog presented here. I have always considered it very silly that you would need a separate program B to alter private data of program A. One should be able to tell Polyglot what 'permanent' settings you want, and how it stores them should be its own business.

To the present-day user it is simply not acceptable that when you have to try a different engine setting, you have to quit GUI and engine, run a separate utility to update an obscure ini file that you might not be able to locate, and then restart the GUI only to find out that the new setting did not exactly do what you wanted, and repeat the process. Even if they could experiment interactively with settings, like the new WinBoard dialog will allow them to do, it will be unacceptable to them to now have to write down the settings, start PolyglotGUI to redo the settings (if they can find the corresponding ini file), to make sure that the next time this engine will start up with the same settings.

I predict that as soon as there are Polyglot versions that can create their own ini file, the ones that cannot will very rapidly be extinct! People just don't want polyglot.ini files. They consider them an abomination...

[F. Bluemers]

Actually the fact that people have to edit polyglot.ini files is the most-frequently given reason why people refuse to use Polyglot, and thus WinBoard. They do not care how much more stable it is, what it can do more, etc. "I would have to edit .ini files with a text edtor." End of story...

This can only be solved offering them a way to edit the ini files with a graphical 'editor' like PolyglotGUI or the WinBoard dialog presented here. I have always considered it very silly that you would need a separate program B to alter private data of program A. One should be able to tell Polyglot what 'permanent' settings you want, and how it stores them should be its own business.

To the present-day user it is simply not acceptable that when you have to try a different engine setting, you have to quit GUI and engine, run a separate utility to update an obscure ini file that you might not be able to locate, and then restart the GUI only to find out that the new setting did not exactly do what you wanted, and repeat the process. Even if they could experiment interactively with settings, like the new WinBoard dialog will allow them to do, it will be unacceptable to them to now have to write down the settings, start PolyglotGUI to redo the settings (if they can find the corresponding ini file), to make sure that the next time this engine will start up with the same settings.

I predict that as soon as there are Polyglot versions that can create their own ini file, the ones that cannot will very rapidly be extinct! People just don't want polyglot.ini files. They consider them an abomination...

I suggest that these users that you mention use the polyglot version of michel
http://alpha.uhasselt.be/Research/Algeb ... t-release/
Best
Fonzy

[hgm]

Sure, that is the Polyglot I referred to at the beginning of this thread. It is the only Polyglot for which the dialog I showed would work. With other Polyglots you would just get an empty dialog (except for the cancel and OK button), no matter how many options the UCI engine had.

[Charles B.]

This can only be solved offering them a way to edit the ini files with a graphical 'editor' like PolyglotGUI...

Just for clarification. I don't think I'm speaking out of turn since it isn't my program but...

Remember that what we now know as the Polyglot_GUI utility, was born in and has always been an integral part of Alex Guerrero's WinMan program. Within the WinMan program the part of the program that is now known separately as the Polyglot_GUI utility/program can be used to edit ini files on the fly. No need to actually even open the ini file with a text editor - ever.

Then Alex took the ini file making capability of his WinMan program and made it available also as a totally separate utility under the name of Polyglot_GUI. From my understanding and experience, the separated Polyglot_GUI utility was meant to be and is best used to make the initial ini file for an UCI engine. Any further editing to the ini file after it has been made with the utility, is best done by hand. An initial ini file maker is what it is. And I use it quite frequently for that purpose. But as an editor for an already existing ini file, no. From within the WinMan program, yes. With the separated utility, no.

[hgm]

OK, so it is even worse than I thought. Because using a text editor is so cumbersome that people justifiable reject it as an option.

What I envision is an environment where people can simply start up WinBoard, and edit the pre-existing polyglot.ini file or create a new one, through the menu. By calling up the Engine-Settings dialog, adjusting the controls, and hit a Save button. It should be as simple as that.

But it makes no sense to have WinBoard read and save polyglot.ini files anymore than having it read and save crafty.ini files. To WinBoard, Polyglot is just an engine, like any other. Engine authors should be free to design their own file format for storing their engine's default settings.

[Charles B.]

OK, so it is even worse than I thought. Because using a text editor is so cumbersome that people justifiable reject it as an option.

I know you weren't making this statement toward the Alex's program but I still want to set the record straight and say that when the Polyglot_GUI was released I thought it to be a work of pure genius and I still think that today. I'm still amazed at its functional simplicity when I use it.

[hgm]

Strange that it cannot be used to edit pre-existing polyglot.ini files, though. That seems only a very small addition, you have to give the name of a polyglot.ini where you want to save anyway. A single button could be added to import the setting from that polyglot.ini file.

But it was not my intention to criticize the implementation of PolyglotGUI. Only the design philosophy where you would need a separate program to do this, where you cannot actually test the effect of the changes. It is jut better to have this functionality intgrated in the GUI.

In addition to the convienience-of-use issue, separte programs also offer logistic problems. PolyglotGUI cannot be legally distributed together with WinBoard. So for our purpose it might as well not exist at all...

[hgm]

A request to you Win98 / ME guys:

Could you try my latest version, to see if it still has this sick behavior? I compared my code to an example I found on the msdn website ( http://msdn.microsoft.com/en-us/library ... S.85).aspx ), and the main difference I found was that they include the WS_CHILD windows style with all the contols they define in the dialog. This might be default in Win 2K/XP/Vista, which would explain why I got away with omitting it, but not in Win 98/ME (which seems to make a popup window in stead of a child window).

The matter about the comboboxes that don't seem to open in Win 2K (aso for me) is still a mystery. When I tried it here, I got the impression (a sublimunal flash) that they do try to open if you click them, but that the drop-down list is somehow covered by the controls below it, so you can't see it. But I might be wrong about this.

[F.Huber]

A request to you Win98 / ME guys:
Could you try my latest version, to see if it still has this sick behavior?

Ok, first the good news: the options window looks much better now (ie. as it should).

But there are still a few problems/questions:
1) the options of type 'spin' are simple text fields (eg. HashSize or SearchDepth in ChestUCI), so you have to enter any values manually and can't choose them by up/down-arrows.
2) as you already mentioned the 'combo' types don't popup the list, but you can select the entries with the down/up-arrow keys (BTW, the width of these combo boxes is too small, try eg. scrolling through the 'SearchMode' list in ChestUCI)
3) and finally I don't really understand (and like) your strange ordering system of these options!
IMO it would be better to fill one complete column (20 or 25 entries) of options, and only for more options start with the next (2nd) column.
As it is now, it's quite confusing: one left, one right, the next again left, then right ...

But you're on the right way now!