WB-engine authors please note!

[hgm]

The latest WinBoard / XBoard release (version 4.3.15) does support commands to set the hash + egtb cache size, Nalimov path and nr of CPUs of SMP engines to the GUI defaults specified in the winboard.ini or through command-line options. UCI engines do already respond to these settings, as Polyglot understands and translates the new WB-protocol commands for setting these parameters.

You are encouraged to also make use of this new possibility in your WB engines, so that they won't lag behind in user-friendliness to their UCI competitors! The commands are quite simple to implement:

At startup of the engine, send:

feature memory=1 smp=1 egt="nalimov"

WinBoard / XBoard will then send your engine, just before every new command:

memory M
egtpath nalimov <pathname>
cores N

where M is the number of megabytes that the engine is allowed to use, and N the number of CPUs. (You can always use less, if that is more convenient!) Even if your engine is not capable of changing its hash-table size at other times than start-up, please let it use the value given by the memory command to determine its start-up size, so that users for which this feature is important can use the work-around of running your engine with the WinBoard -xreuse option, so that it is restarted before every game. If accepted memory is amongst the GUI reply to your feature commands, rather than rejected memory, you cansafely postpone your initialization until after you receive the first memory command, as the GUI will certainly send it before sending anything other than the accepted / rejected responses to the features.

For exact description of the commands as they work in WinBoard 4.3.15, see the extended WB protocol specs.

[bob]

The latest WinBoard / XBoard release (version 4.3.15) does support commands to set the hash + egtb cache size, Nalimov path and nr of CPUs of SMP engines to the GUI defaults specified in the winboard.ini or through command-line options. UCI engines do already respond to these settings, as Polyglot understands and translates the new WB-protocol commands for setting these parameters.

You are encouraged to also make use of this new possibility in your WB engines, so that they won't lag behind in user-friendliness to their UCI competitors! The commands are quite simple to implement:

At startup of the engine, send:

feature memory=1 smp=1 egt="nalimov"

WinBoard / XBoard will then send your engine, just before every new command:

Why before the "new" command and not after? "new" is supposed to reset the engine to normal default values for the start of a new game. It would seem that any commands to change engine settings should happen _after_ that. Although to be honest, I see no reason to send such commands either before or after a "new", just once at the beginning when the engine is initially executed...

memory M
egtpath nalimov <pathname>
cores N

where M is the number of megabytes that the engine is allowed to use, and N the number of CPUs. (You can always use less, if that is more convenient!) Even if your engine is not capable of changing its hash-table size at other times than start-up, please let it use the value given by the memory command to determine its start-up size, so that users for which this feature is important can use the work-around of running your engine with the WinBoard -xreuse option, so that it is restarted before every game. If accepted memory is amongst the GUI reply to your feature commands, rather than rejected memory, you cansafely postpone your initialization until after you receive the first memory command, as the GUI will certainly send it before sending anything other than the accepted / rejected responses to the features.

For exact description of the commands as they work in WinBoard 4.3.15, see the extended WB protocol specs.

[hgm]

When people change the parameters using the menu, they have to be re-sent, or the engine would never know it. Changing the hash size during a game seemed rather disruptive, so I limited that to doing it only before the engine really starts playing.

Initially I did sent them all after new, because that seemed more logical to me as well, but in practice that turned out to cause problems in communication with UCI engines (through Polyglot). Some UCI engines do not accept some option settings after they have received the UCI 'isready' command, so Polyglot must delay the sending of this command until it is sure that it has seen all options settings that XBoard is going to send (and relayed them to the engine). If they are sent after the new, there is no suitable WB command Polyglot can wait for to be sure all options are in: it is likely that the GUI will send a ping when it is done initializing the engine, but WB protocol does not guarantee it. A new command is guaranteed to come, though. So we implemented it such that Polyglot waits for the new as a sign that all options have been sent, to ensure backward compatibility of the new Polyglot with all existing WB-compatible GUIs.

Most UCI engines seem to have no problems with changing the hash size between games without re-starting. So there was no reason to limit the sending of this command to start-up only. The cores command can even be sent at any time, when the user decides to change it. (Like you can switch Ponder on and off at any time you want.)

[hgm]

I can add that I now also have a trial version of XBoard that implements the setting of engine-defined options through an XBoard menu, similar to what is possible with UCI engines. This is something I could include in a future release, if there is sufficient interest for it.

The way I implemented it is that the engine defines options at start-up through sending feature commands, like

feature option="MYOPTION -spin VALUE MIN MAX"

which would be the WB protocol equivalent of the UCI command

option name MYOPTION type spin default VALUE min MIN max MAX

(where the capitalized words should be replaced by an arbitrary text string and three integers, respectively). XBoard creates a menu popup according to the specification for the option, and whenever the user would use the menu to alter the value of an option, XBoard sends

option MYOPTION NEWVALUE

to the engine.

Would there be any interest amongst engine authors to use such a feature on their engines? My first experience is that it seems pretty useless, unless the engine remembers its option settings from one invocation to the next. Of course for playing-style options it might not be a big problem if at start-up the engine always reverts to its default style, and users would have to select the one they really want before they start playing. But on an engine with many options of a less volatile character, it would be a pain if the engine did not remember them.

Of course the engine could provide options for which of its settings to remember, and when, in the very same options menu, by defining a button 'save engine settings' there, or 'change defaults', or whatever. That would be entirely up to the engine.

Feedback welcome! Send me a PM if you want to have a trial version of XBoard that implements this. (Not available in WinBoard yet, as I don't know how to make dynamically formatted dialofgs in Windows; in WinBoard all menus are statically defined.)

[Michel]

Probably this subject would be more natural on the wbforum but as the thread was initiated here I'll reply here.

The main question is:

Who should save settings for an engine? Winboard/Xboard or the engine.

I think it should be the Winboard as this is what all other GUIs do but H.G. Muller thinks it should be the engine.

His main argument is that WB is not an engine manager but a tool to make two engines play with each other. A true engine manager can still supply options to engines at startup through the initString option.

Making the engine save the options entails a modification of polyglot so I would like to hear some input on this.

[hgm]

Actually, I would prefer if neither WinBoard / XBoard nor engine would have to save anything, but that the tournament manager did this. Then WinBoard / Xboard would nt need any new menus at all, and could completely ignore the feature option="..." commands. They would only be sent by the engine for the purpose of communicating with the tournament manager, when the engine is being configured and installed int he engine database.

Originally I added this feature to XBoard only as a convenient way to create polyglot.ini files for an engine, so it can be used as an alternative to, say, Polyglot GUI. But of course Polyglot ini files are a curse, and if the user has to be aware of their existence, it is a sure sign of bad design of the Chess environment.

[Michel]

But of course Polyglot ini files are a curse, and if the user has to be aware of their existence, it is a sure sign of bad design of the Chess environment.

Well command line people like me may like the .ini files. I always start xboard with

Code: Select all

xboard -fcp "polyglot <some.ini>"

and do not rely on xboard to write the .ini file for me.

But ini files are not so good for setting options through a GUI. Basically something like this would be better.

polyglot -engineCommand <engine> -engineDir <dir> -engineName <name>.

This is just enough information to start the engine and give it a name. Other options can then be set through the GUI.

They would only be sent by the engine for the purpose of communicating with the tournament manager, when the engine is being configured and installed int he engine database.

You mean the TM would start the engine itself to have a look at what kind of options it supports?

[hgm]

You mean the TM would start the engine itself to have a look at what kind of options it supports?

Exactly. To install a new engine you would just click the executable in the file selector dialog, and create a name for it. The engine manager would then interrogate the engine, and depending on what is learned, do the rest. (Substituting Polyglot for the engine command if the engine is UCI, and prepare a polyglot.ini file for it, possibly importing the settings from a pre-existing polyglot.ini in a standard location.)

Why exactly is the engineName needed? Don't UCI engines define their own name?

[krazyken]

Why exactly is the engineName needed? Don't UCI engines define their own name?

Some times I like to give a name to a particular set of settings, so that different configurations of the same engine can be compared.

[hgm]

OK, I see. So the name given in the polyglot.ini (or as the newly proposed Polyglot argument) would overrule the name the engine specifies.

But if the idea is to run Polyglot without using any ini file, just based on its command-line options, all UCI options would remain at their defaults, (until they are changed by the GUI through WB protocol), and altering the engine name would be hardly useful.