Can anyone test this

[Pablo Vazquez]

If 'Threads' sets the number of CPUs in SMP it is not an engine-specific option, but a general option, controlled by the WinBoard 'cores' command. This is controlled from the Options -> Global Settings... dialog, together with things like hash-table size, EGTB path, GUI book.

Ok, in that case it works fine.

[hgm]

I just posted a new version (4.4.1e) because the previous one added a phantom option at the end of the list, which in practice behaved as an alias of the first option, with inconsistent result for the setting of that option.

If I should believe the Polygot logfile, all option types seem to arrive at the engine.

[bob]

I have added a menu to WinBoard to set the engine-specific options of UCI engines. The major problem is: how to test it? So I have this request:

Could everyone take his favorite UCI engine, and run it with the aid of the winboard alpha on my website, and Michel van den Bergh's new Polyglot 1.4.33b?

All that is needed is to save the Polyglot in the same folder as the (unzipped) winboard.exe under the name polyglot.exe (so no fancy numbers in the name, or WinBoard would not automatically find it). Then all that is needed is to startup WinBoard through the startup dialog, and type in the first-engine field:

ENGINE.exe /fd=ENGINEFOLDER /fUCI

When you then click the Options -> Engine #1 Settings menu, there should pop up something like:



Could you then play the engine, and somehow figure out if it indeed reacts to changing of the settings you make through this menu? That would be immensely helpful!

BTW, I was playing Crafty vs the newest Stockfish last night and was comparing the logs as the game progressed. I was amazed to see that for each search by stockfish, polyglot was sending a FEN position for the starting position I used, then it sent all the moves played so far, then said "go"

What an incredibly stupid way of designing a protocol. Let's wipe out everything between moves?

sheesh...

[hgm]

Indeed, such are the blessings of stateless protocols.

Note, however, that this new option menu is not limited to UCI engines: WinBoard engines can use it too. If you would want to allow Crafty users to switch on or off the Crafty log file, all you would have to do is make Crafty send to WinBoard at startup:

feature option="MakeLog -check 0"

amongst the other feature commands. The user would then get to see a checkbox in the Crafty Settings dialog with the text "MakeLog" next to it (unchecked, because the 0 meant "off"). And when he would check it and press OK, WinBoard would send to Crafty:

option MakeLog=1

to tell Crafty it has to start logging. (For MakeLog you could take any other name you like. There will be no other description in the dialog box than the name of the option, though, so it should better be something that a user will recognze andunderstand what it is for.) Simiarly, if you want the name of the log file settable from the GUI menu, Crafty coud say at startup:

feature option="LogFile -string crafty.log"

and the user would get to see a text-edit in the Crafty Settings dialog initialied to "crafty.log". If he would change that to "foo" and press OK, WinBoard would send to Crafty:

option LogFile=foo

Engines could still continue to use ini files for defining such option settings, but they could use the settings defined in those ini files merely as initial values for the options (which they would then use in the feature option="..." commands to tell WinBoard what the initial option setting is), and only change them when they receive the corresponding option foo=... command.

[Spock]

BTW, I was playing Crafty vs the newest Stockfish last night and was comparing the logs as the game progressed. I was amazed to see that for each search by stockfish, polyglot was sending a FEN position for the starting position I used, then it sent all the moves played so far, then said "go"

What an incredibly stupid way of designing a protocol. Let's wipe out everything between moves?

sheesh...

I've never used polyglot, but this sort of thing is why I refuse to use adaptors now. You just don't know what is going on behind the scenes. Better to use a GUI like Arena or ChessGUI that supports both protocols directly, if you want to mix up UCI and Winboard.

[F. Bluemers]

BTW, I was playing Crafty vs the newest Stockfish last night and was comparing the logs as the game progressed. I was amazed to see that for each search by stockfish, polyglot was sending a FEN position for the starting position I used, then it sent all the moves played so far, then said "go"

What an incredibly stupid way of designing a protocol. Let's wipe out everything between moves?

sheesh...

I've never used polyglot, but this sort of thing is why I refuse to use adaptors now. You just don't know what is going on behind the scenes. Better to use a GUI like Arena or ChessGUI that supports both protocols directly, if you want to mix up UCI and Winboard.

Its the protocol,using a gui won't change anything.

[Spock]

Its the protocol,using a gui won't change anything.

So that's the UCI protocol ? Hmm....
But my comment still stands, I don't use adaptors.

[F. Bluemers]

Indeed, such are the blessings of stateless protocols.

Note, however, that this new option menu is not limited to UCI engines: WinBoard engines can use it too. If you would want to allow Crafty users to switch on or off the Crafty log file, all you would have to do is make Crafty send to WinBoard at startup:

feature option="MakeLog -check 0"

amongst the other feature commands. The user would then get to see a checkbox in the Crafty Settings dialog with the text "MakeLog" next to it (unchecked, because the 0 meant "off"). And when he would check it and press OK, WinBoard would send to Crafty:

option MakeLog=1

to tell Crafty it has to start logging. (For MakeLog you could take any other name you like. There will be no other description in the dialog box than the name of the option, though, so it should better be something that a user will recognze andunderstand what it is for.) Simiarly, if you want the name of the log file settable from the GUI menu, Crafty coud say at startup:

feature option="LogFile -string crafty.log"

and the user would get to see a text-edit in the Crafty Settings dialog initialied to "crafty.log". If he would change that to "foo" and press OK, WinBoard would send to Crafty:

option LogFile=foo

Engines could still continue to use ini files for defining such option settings, but they could use the settings defined in those ini files merely as initial values for the options (which they would then use in the feature option="..." commands to tell WinBoard what the initial option setting is), and only change them when they receive the corresponding option foo=... command.

Looks very nice indeed.
where will winboard save the settings the user changed?
Best
Fonzy

[hgm]

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.

[hgm]

So that's the UCI protocol ? Hmm....
But my comment still stands, I don't use adaptors.

You should just never use UCI engines. That protocol really sucks...