Some more WB protocol extensions

[hgm]

To keep track of the 'score':

After what has been said so far, and reading back through earlier discussions on protocol extensions in Tim's xboard e-mail folder (which he kindly made available to me), I have moved to the opinion that:

A separate reset command should be added to the protocol, under control of feature reset=1 (a boolean feature, default 0). XBoard would not implement it, as it has no use for it. (As long as we have no EPD-suite functionality.)

The implementation of telluser and tellusererror in XBoard should be enhanced to alow multi-line messages through \n escapes in the MESSAGE. The specs should contain the _recommendation_ GUIs should recognize such escape sequences in the MESSAGE.

Add feature author="STRING" and feature country="STRING" , to the specs. XBoard would not implement them.

Under control of a feature post=1, (a boolean feature, default 0), the post command would be allowed to have two integer parameters (i.e. post T1 T2) that control the frequency of posting of Thinking Output lines (by specifying a minimum and maximum time interval in centi-seconds).

The extended format for Thinking Output can be put in the specs; I will change the proposed ++ and -- indicators for fail-high / fail-low by !! and ??, however, to avoid confusion with ++ indicating checkmate. In XBoard I will match the pattern at the beginning of the old PV field, and divert the information there to the place where stat01 information is displayed now (in the Engine-Output window). Possibly suppressing lines that are duplicates of the previous line in other respects.

The multipv N command under control of feature multipv=1 (a boolean option, default 0) can be implemented in XBoard as proposed. Apart from providing the user interface to switch it on, this would only involve sorting of the Thinking Output lines of the current iteration by score in the Engine-Output window; i.e. not inserting the new line always at the top, but insert it in the place indicated by its score.

The level MPS TC INC [MPS2 TC2 INC2 ...] command under control of the feature xlevel=1 (a boolean feature) can be implemented as proposed.

[hgm]

OK, I have started writing up the extensions to the protocol specs. How about this for the multi-session time controls?

When the engine has sent "feature xlevel=1" at startup, (or when the user explicitly has requested so), "level" commands can also be sent during a game, just before relaying the opponent move. The number of moves given in such an intra-game "level" command (when non-zero) should be interpreted as the number of moves still to do from now on, before it will receive a new time alotment (other than the increment). The time given should be interpreted as the time left on its cock. and not necessarily the time that will be added to the clock after the specified number of moves has been played. XBoard 4.4.2+ uses this to implement multi-session time controls. Example: if at the start of the game "level 40 60 0" was given (40 moves per hour), and the engine receives "level 20 22 0" just before move 41, it should understand that the color it is playing now should do the next 20 moves (i.e. 41-60) in 22 minutes (pehaps because the secondary session was 20 moves per 15 minutes, and it had 7 minutes left on its clock after the first 40 moves).

Note that a new "level" command always overrules any previous "level" or "st" command, even when you receive it at an unexpected time (i.e. before the session you are currently playing is supposed to end). Whenever the engine receives "level MPS TC INC ...", it means that a new session starts now, and that (apart from the INC every move) it should not expect to get a new time alotment before MPS moves have been played from now. A decent implementation of muti-session time controls would only send new "level" commands at the start of each session, and would inform the engine truthfully in advance of what it can expect in all future sessions, in the second and later groups of MPS, TC, INC parameters sent with the level command. A GUI should not rely on the engine to remember any of this advance information, and send new "level" commands whenever a session with different parameters starts. There can be an arbitrary number of sessions specified by the level command. If more are specified than your engine can handle, just ignore them.

Code: Select all

before move  1: level 40 60 0 20 15 0 0 5 1
before move 41: level 20 15 0 0 5 1
before move 61: level 0 5 1

The above examples show what xboard would send when for a 40/60+20/15+5+1 game, (assuming the engine fully used its time in all sessions), i.e. first a session of 40 moves in 60 min, then one of 20 moves in 15 min, and then 5 more min plus 1 sec per move for the rest of the game. If the last session mentioned is a classical session (MPS > 0), it is supposed to repeat indefinitely. Failure to send the level command before move 41 in the example will result in explicitly undefined behavior: the engine might remember the 20 15 0 from the initial "level" command, but it might also play another 40 60 0 session. Note that the protocol also supports "treacherous" implementations of multi-session time controls, where you ly to the engine about what it should expect, and that the engine should be able to handle this without complaining. Also note that normally the time to put on the clock is immediately overruled by a "time" command that will follow the "level" command, and will only be of importance to engines that have suppressed sending of the "time" command. When an engine is made to change sides during a game, it should assume the opponent has received the same "level" commands on the same moves as it has received itself, but will be informed of the time left on the clock of this side by the "time" command.

[Don]

I was simply objecting to the use of the word "hideous" for a command that allows the GUI to ask information from the engine.

There is no need to use such charged words when discussing a communication protocol.

I think he used the right word in this case. I'm not going to be too critical of the words he uses since we all benefit from xboard and he does all the work.

- Don

[frankp]

I was simply objecting to the use of the word "hideous" for a command that allows the GUI to ask information from the engine.

There is no need to use such charged words when discussing a communication protocol.

I think he used the right word in this case. I'm not going to be too critical of the words he uses since we all benefit from xboard and he does all the work.

- Don

Is there any similar ongoing development of xboard (Linux version)? I am still on 4.2.7.

[hgm]

Is there any similar ongoing development of xboard (Linux version)? I am still on 4.2.7.

Sure there is. The current version available from the GNU website is XBoard 4.4.0, which is also available from Debian. The Ubuntu repository is still at 4.4.0~beta1. In a few days (perhap even later today) 4.4.1 sources will be available from GNU. They can already be downloaded from the git repository, but still have to be tagged as 4.4.1 and packed into a distribution tar ball.

XBoard 4.4.1 is mainly a bug-fix version, (compared to 4.4.0), especially for bugs in ICS play. The WinBoard counterpart does have some new features, though, in particular the ICS chat windows.

The things I am discussing here is for after 4.4.1, though.