UCI issues

[michiguel]

Who is supposed to store the parameters info modified with setoptions? The GUI or the engines? I can make the engine save them, but I do not want to break common usage.

I have been trying the Shredder GUI demo in Linux. There is a an option to save as new engine, but I never see that "new engine" anywhere. All the parameters I modified, are erased in the next game.

Is it me or this GUI is buggy? I have seen that sometimes it does not send the ponder parameters after go, when it should, and I cannot modified any parameter during the game because it stops sending any commands to the engine (I guess it assumed that the game is over but the clock kept ticking). The UCI protocol is supposed to have the advantage that you could change anything and the engine should take it easily, because of the stateless spirit, but the GUI here does not follow that spirit.

Where is the option OwnBook supposed to appear? I do not see it anywhere in the GUI.

Is the Shredder GUI in Linux very different from Windows?

Another thing, related to the protocol: How is the engine supposed to know when is "just" out of book (to make it think longer)? I guess there is no straightforward way?

Miguel

[zamar]

Who is supposed to store the parameters info modified with setoptions? The GUI or the engines?

GUI, I assume.

Another thing, related to the protocol: How is the engine supposed to know when is "just" out of book (to make it think longer)? I guess there is no straightforward way?

First 'go' after 'ucinewgame'?

[Gian-Carlo Pascutto]

First 'go' after 'ucinewgame'?

That breaks in UCI interfaces that do not send ucinewgame.

Most straightforward way is to remember whether the last move was from book or not.

[zamar]

First 'go' after 'ucinewgame'?

That breaks in UCI interfaces that do not send ucinewgame.

Well, it's true that some old or buggy GUIs don't support it, so you should not write anything critical relying it. However when it comes to allocating some extra time for first non-book move, nothing is going to break if this doesn't get right under some GUI.

[michiguel]

First 'go' after 'ucinewgame'?

That breaks in UCI interfaces that do not send ucinewgame.

Well, it's true that some old or buggy GUIs don't support it, so you should not write anything critical relying it. However when it comes to allocating some extra time for first non-book move, nothing is going to break if this doesn't get right under some GUI.

I just saw that Aquarium demo does not even respect the engines time management. Rather than waiting for "bestmove <move> ponder <move>", it sends a brutal "stop". In one of the test games I (as a human) was playing against gaviota, the GUI interrupted gaviota in the middle of a fail low and forced it to make a decision with a "stop", according to the logs.

I think I should not worry about any of this. Dealing with GUIs who behaved like this is going to be futile.

Miguel

[michiguel]

First 'go' after 'ucinewgame'?

That breaks in UCI interfaces that do not send ucinewgame.

Most straightforward way is to remember whether the last move was from book or not.

I was trying to avoid that and add extra code in case of an external book...

If the GUI sends ucinewgame, the first go is a good hint and possibly a good compromise, but still not perfect. If the engine comes out of book, and get into book again (it happens) it won't detect it.

Miguel

[Jaap Weidemann]

Who is supposed to store the parameters info modified with setoptions? The GUI or the engines? I can make the engine save them, but I do not want to break common usage.

I have been trying the Shredder GUI demo in Linux. There is a an option to save as new engine, but I never see that "new engine" anywhere. All the parameters I modified, are erased in the next game.

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.

Is it me or this GUI is buggy?

It's not you .

Where is the option OwnBook supposed to appear? I do not see it anywhere in the GUI.

Last time I checked both the Linux and Mac versions does not support the OwnBook option. The Windows version supports it.

Is the Shredder GUI in Linux very different from Windows?

Luckily the answer is yes.

Jaap
http://www.weidchess.com/

[hgm]

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.

[Teemu Pudas]

I just saw that Aquarium demo does not even respect the engines time management. Rather than waiting for "bestmove <move> ponder <move>", it sends a brutal "stop".

It does the same in infinite analysis after 2 seconds. Hence, "demo".

[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/