WB protocol (and UCI?) extension proposal

[hgm]

It seems that WinBoard protocol does not provide any feature equivalent to UCI "searchmoves", which limits an analysis search to a given subset of root moves. People using engines for analysis seem to consider this a feature of crucial importance. In addition, it seems to be important to be able to assign scores to certain positions in the tree by hand. (A manual form of EGTB probing, as it were.) Some engines support a "session file" for this, and it seems desirable to have GUI support for manipulating the contents of this file.

What I propose is to add a new GUI->engine command

kill MOVE

which the GUI could use on engines that at startup say

feature exclude=1

to strike the mentioned root move from the current search. (Presumably this would mean that the search of the remaining moves would be restarted at low depth, but in cases where the previous iteration already had another move as best, it would be perfectly allowed to start from that iteration.)

Note that the Polyglot included with WinBoard 4.6.0 can also do this through an engine-defined option, called "Polyglot exclude move", which can be set by hand through the Engine Settings dialog, but for the GUI to use this command in response to some user mouse action, it seems better to enforce some standardization. This standardization could of course also be achieved by requiring the engine-defined option to have a specific name, but that goes a bit against the design philosophy of WB protocol.

For the session-file stuff I am less certain. The variety of implementations of this found in different engines is likely to be wider, making the use of an engine-defined option more natural. Also because in the most elaborate implementation, allowing the user to specify a score and depth to a given position, inherently seems to require keyboard input. And the Engine Settings dialog would be as good a popup for this to enter the required info as any.

There is one case where I imagine GUI assistence could be useful, though: the existing Adjudicate to White/Black and Adjudicate Draw items in the WinBoard Action menu could be used in a natural way to define the score of the current position as +/-30000 cP or 0, respectively, valid to any depth. But to achieve that, the GUI would need to know what option to send.

So it would seem useful to define an engine->GUI command

setscore SCORE DEPTH

which tells the engine to include the current position in its session file with SCORE centi-Pawn (from side-to-move POV, as always in WB protocol) with a depth limit of DEPTH ply. This would be subject to an initial

feature setscore=1

WB engines could use these options without problems, but setscores would only be implementable in Polyglot if there also was standardization of this option on the UCI side. (For "searchmoves" there already is.) I therefore want to propose UCI engines, wanting to make their session file approachable to the user through the GUI interface, would (as a minimum) supply the option

setoption name UCI_setscore SCORE

after the usual announcement

option name UCI_setscore type spin default 0 min LOSSSCORE max WINSCORE

so that Polyglot would know how to translate the setscore command. (Use of this option would imply validity of the given score to infinite depth.) It is up to the engine what other options it wants to provide for allowing the user access to its session file, and how long the effect of using the above option should last. (E.g. if there are buttons to clear (parts of) the session file, or save changes in it on a user-specified file.)

[JuLieN]

I won't comment on H.G.'s technical proposals above, and will just make a suggestion I'm thinking about for a while: adding a "comment" command (engine>Interface). Such comments would be displayed in a dedicated window in the interfaces (a bit like a chat or a kibitz), or just ignored. That would allow the engine to make comments on the game.

For instance:

comment I'm switching to table bases.
comment I'm out of book.
comment This position is the most tactical one I've met, with up to 27 captures possible.
etc...

You name it...

[hgm]

...: adding a "comment" command (engine>Interface). Such comments would be displayed in a dedicated window in the interfaces (a bit like a chat or a kibitz), or just ignored. That would allow the engine to make comments on the game.

This already exists. The command is "#". Any line starting with it will be ignored by the GUI, provided that the engine at startup announced this by "feature debug=1". (The idea was that a GUI not supporting this would reply with "rejected debug", so the engine could know that it has to show restraint in sending non-compliant output, and cannot assume that prefixing a line with "#" will completely disarm it.) There currently is no dedicated window to display this stuff, but it will be written in the debug file. In XBoard you can see the debug file real-time by setting -dbug -debugfile stderr, after which all debug output will appear in the terminal window from which XBoard was started.

comment This position is the most tactical one I've met, with up to 27 captures possible.

Note that for comments of this type, WB protocol has the telluser command available, with causes a popup. This will always be a new one, though, and won't append the line to any pre-existing messages. But that is more a matter of implementation than a protocol matter. Other GUIs could choose to accumulate such messages in one window. In XBoard I could imagine an option -collectEngineTells true|false to get this behavior in stead of the current one.

Not that it is also possible to disguise messages you want the user to see as thinking output, so that it will be displayed in the Engine Output window. XBoard treats thinking-output lines of the format

n 0 0 0 MESSAGE

as special. (The get less indent in the Engine Output window than a PV.) Polyglot uses this to pass UCI "info string MESSAGE" commands to the user.

[Daniel Shawul]

Is there additional benefit to do a restricted analysis on a give set of root moves rather than using multip pv ? I guess even with the former you still have to use multipv otherwise the scores of the moves will be the same except for the first one. Also the gui should be told which set of moves to work on which makes things even more uglier.

As to the session file , it seems a little strange that such kind of work is offloaded to the GUI. I never used it but if the leaf node is not on the main line, it will not have any effect. And if it is the score is already known , so why analyze ? If that have to be supported, I think an option to print tree using tree mapping or something else is also good.

[hgm]

Well, I am only relaying user requests, as I never do any analysis myself. But several people agreed that this is ssential, and multi-PV is way to slow. The problem is that multi-PV keeps wasting time on what the engine perceives as the best move, even when the user already decided there is no way he is going to play that.

The session-file stuff seems to be important when you have fortresses a user can recognize, but the engine can't. (E.g. positions where a wall of Pawns can be created to separate both sides.)

[Ferdy]

This is a good feature for sure, to kill other moves.
kill MOVE2
kill MOVE3
kill MOVE4

then to include back
unkill MOVE2
unkill ALL

In other gui, there is a menu of check boxes with move labels and the user will just check or uncheck the moves. Like menu "include", all check boxes with check will be included in the analysis and check boxes without check will not be included in analysis. There is also menu "exclude" when check boxes are checked those moves will be excluded.

[michiguel]

...: adding a "comment" command (engine>Interface). Such comments would be displayed in a dedicated window in the interfaces (a bit like a chat or a kibitz), or just ignored. That would allow the engine to make comments on the game.

This already exists. The command is "#". Any line starting with it will be ignored by the GUI, provided that the engine at startup announced this by "feature debug=1". (The idea was that a GUI not supporting this would reply with "rejected debug", so the engine could know that it has to show restraint in sending non-compliant output, and cannot assume that prefixing a line with "#" will completely disarm it.) There currently is no dedicated window to display this stuff, but it will be written in the debug file. In XBoard you can see the debug file real-time by setting -dbug -debugfile stderr, after which all debug output will appear in the terminal window from which XBoard was started.

comment This position is the most tactical one I've met, with up to 27 captures possible.

Note that for comments of this type, WB protocol has the telluser command available, with causes a popup. This will always be a new one, though, and won't append the line to any pre-existing messages. But that is more a matter of implementation than a protocol matter. Other GUIs could choose to accumulate such messages in one window. In XBoard I could imagine an option -collectEngineTells true|false to get this behavior in stead of the current one.

Not that it is also possible to disguise messages you want the user to see as thinking output, so that it will be displayed in the Engine Output window. XBoard treats thinking-output lines of the format

n 0 0 0 MESSAGE

as special. (The get less indent in the Engine Output window than a PV.) Polyglot uses this to pass UCI "info string MESSAGE" commands to the user.

We need a command ("chat") that is specified NOT to be a pop up. Telluser may or may not be a pop up, which is annoying. That is the reason I do not use it at all. Gaviota has been limited to send smilies after the PV, but Fern requested me to expand this feature so the engine can talk to the user continuously. ("I am kicking your butt", "I think I will lose soon", etc.). However, whatever is available now is not suitable for this.

So I think I join Julien in this request. I think it is very important for the user experience.

Miguel


Miguel

[michiguel]

It seems that WinBoard protocol does not provide any feature equivalent to UCI "searchmoves", which limits an analysis search to a given subset of root moves. People using engines for analysis seem to consider this a feature of crucial importance. In addition, it seems to be important to be able to assign scores to certain positions in the tree by hand. (A manual form of EGTB probing, as it were.) Some engines support a "session file" for this, and it seems desirable to have GUI support for manipulating the contents of this file.

What I propose is to add a new GUI->engine command

kill MOVE

which the GUI could use on engines that at startup say

feature exclude=1

to strike the mentioned root move from the current search. (Presumably this would mean that the search of the remaining moves would be restarted at low depth, but in cases where the previous iteration already had another move as best, it would be perfectly allowed to start from that iteration.)

Note that the Polyglot included with WinBoard 4.6.0 can also do this through an engine-defined option, called "Polyglot exclude move", which can be set by hand through the Engine Settings dialog, but for the GUI to use this command in response to some user mouse action, it seems better to enforce some standardization. This standardization could of course also be achieved by requiring the engine-defined option to have a specific name, but that goes a bit against the design philosophy of WB protocol.

For the session-file stuff I am less certain. The variety of implementations of this found in different engines is likely to be wider, making the use of an engine-defined option more natural. Also because in the most elaborate implementation, allowing the user to specify a score and depth to a given position, inherently seems to require keyboard input. And the Engine Settings dialog would be as good a popup for this to enter the required info as any.

There is one case where I imagine GUI assistence could be useful, though: the existing Adjudicate to White/Black and Adjudicate Draw items in the WinBoard Action menu could be used in a natural way to define the score of the current position as +/-30000 cP or 0, respectively, valid to any depth. But to achieve that, the GUI would need to know what option to send.

So it would seem useful to define an engine->GUI command

setscore SCORE DEPTH

which tells the engine to include the current position in its session file with SCORE centi-Pawn (from side-to-move POV, as always in WB protocol) with a depth limit of DEPTH ply. This would be subject to an initial

feature setscore=1

WB engines could use these options without problems, but setscores would only be implementable in Polyglot if there also was standardization of this option on the UCI side. (For "searchmoves" there already is.) I therefore want to propose UCI engines, wanting to make their session file approachable to the user through the GUI interface, would (as a minimum) supply the option

setoption name UCI_setscore SCORE

after the usual announcement

option name UCI_setscore type spin default 0 min LOSSSCORE max WINSCORE

so that Polyglot would know how to translate the setscore command. (Use of this option would imply validity of the given score to infinite depth.) It is up to the engine what other options it wants to provide for allowing the user access to its session file, and how long the effect of using the above option should last. (E.g. if there are buttons to clear (parts of) the session file, or save changes in it on a user-specified file.)

Gaviota has this implemented already, but it is called "exclude" rather than kill. So, if you want an engine to test this, it will take me seconds to change it and also send "feature exclude=1" at the beginning. But, why not use "exclude" rather than "kill"? (not really important).

I also have implemented "include", and "include all" (IIRC). Not sure it is needed, but only important if it is used manually in the terminal.

Miguel

[Ferdy]

I won't comment on H.G.'s technical proposals above, and will just make a suggestion I'm thinking about for a while: adding a "comment" command (engine>Interface). Such comments would be displayed in a dedicated window in the interfaces (a bit like a chat or a kibitz), or just ignored. That would allow the engine to make comments on the game.

For instance:

comment I'm switching to table bases.
comment I'm out of book.
comment This position is the most tactical one I've met, with up to 27 captures possible.
etc...

You name it...

I agree this is very interesting and more fun when implemented.
Gui can also comment about the position.

Fritz 13 sample comment, from french defence opening.
[d]rnbqkb1r/pppn1ppp/4p3/3pP3/3P4/2N5/PPP2PPP/R1BQKBNR w KQkq - 0 5
"Black has a cramped position; Black's piece can't move: c8"


and then some moves later.
[d]r1bqk2r/5ppp/p1n1p3/1pnpP3/5P2/2N2N2/PPP2QPP/R3KB1R b KQkq - 0 11
"White threatens to win material: Qf2xc5"

[hgm]

Well, if it is also useful to have the opposite, then I would definitely prefer include/exclude over kille/unkill. So leave it as it is. Currently WinBoard does not implement this at all, and I will adapt to Gaviota. I only have implemented it in Polyglot as a "sleeper feature", using "kill". But then I will change that there to "exclude" (abandoning the fine tradition of WB protocol to have silly command names... ), and implement the "include" as well.

Currently I only tested the UCI searchmoves implementation in Polyglot using the synonym of the "exclude" command appearing as an engine-defined option in the Engine-Settings dialog. (It seemed to work with Glaurung: after 1. e4 f5 Glaurung likes 2.exf5, and typing e4f5 for the option made Glaurung switch to e5, and then typing e4e5 made it change to Nc3.)

A problem is still how to implement this in a game-state-unaware adapter like UCI2WB. I guess I will have to make it collect the move list from the engine's currmove commands. A rule-unaware GUI could then request it from the adapter. This has the advantage anyway that it could present the moves in engine-order, so that the most relevant moves presumably are near the top of any presented table. I am thinking of using the WB "bk" command for this, requiring an engine to send all legal moves from the current position when it receives it in analysis mode.

As to the "chat" stuff: I am not too keen on giving the engine a say in GUI matters. It should be the user's choice if he prefers to see white or black at the bottom, wants to see the PV as SAN or long-algebraic, or wants to see engine tells as popups or a chat (or not at all). The engine's task should be limited to providing content.

I know that XBoard has an option auto-comment, but I think this is not used outside ICS mode. It would be nice to also give it a meaning in engine mode, so that engine utterances could be incorporated in the PGN.