xboard protocol question

[Dave_N]

I am new to using the xboard protocol ...

My communication with the engine goes like this ...

xboard
protover 2
// engine lists features

now I tested loading crafty at the command line and tried to reject some features to set "san=0" to keep the processing method equal to the UCI protocol I use, the result is "Error. feature san rejected by xboard." I am guessing the GUI has to use all modes ?

[hgm]

If you only support the protocol partially, you won't be able to run some engines that also do that.

[Dave_N]

Yes I agree, however I suppose I want to know if the engine does have "san=0" mode when it is listed in the features as "feature san=1".

Basically the "subset" of functionality is for a GUI mode to supply an approximately equal engine vs engine match and to make the first version functional asap (i.e. this week).

[Dave_N]

My SAN-to-LAN function is probably slower than my LAN-to-SAN function ...

[Evert]

Yes I agree, however I suppose I want to know if the engine does have "san=0" mode when it is listed in the features as "feature san=1".

I think you misunderstand the feature list here. There is no "san=1" or "san=0" mode. The engine is telling the interface that it supports sending and receiving moves in SAN. If the interface doesn't want to do that it should reject the SAN feature.

[Dave_N]

Yes I agree, however I suppose I want to know if the engine does have "san=0" mode when it is listed in the features as "feature san=1".

I think you misunderstand the feature list here. There is no "san=1" or "san=0" mode. The engine is telling the interface that it supports sending and receiving moves in SAN. If the interface doesn't want to do that it should reject the SAN feature.

Well that's what I am checking on ... I found this in the xboard protocol page
option NAME[=VALUE]
and could not use it (using version 2)

Also When I send moves in LAN the engine (crafty) will recieve the move and reply in SAN, so a typical blindfold game could go like this

e2e4
move c5
g1f3
move e6

etc.

[Dave_N]

I would expect my SAN-LAN function is fast enough however maybe not perfect for hyper-bullet games that could be played with the simple LAN format :/
the SAN-LAN function in my code base is basically tuned towards error checking pgn files not in fast LAN/coordinate move generation, so I guess I'll have to write that function again for parsing engine output -- the fun part ofc

[Evert]

Well that's what I am checking on ... I found this in the xboard protocol page
option NAME[=VALUE]
and could not use it (using version 2)

That's because "san" is a feature, not an option. The engine tells the interface what features it supports. If you think about it, it doesn't make sense for the interface to tell the engine which features it supports.

Look at the "option" command in the "xboard to engine" section and the "feature" command in the "engine to xboard" section.

[Dave_N]

I looked earlier and noticed this ...

option NAME[=VALUE]
This command changes the setting of the option NAME defined by the engine (through an earlier feature command) to the given VALUE.

and the Engine to Xboard section was looking promising until I got to the last paragraph

feature FEATURE1=VALUE1 FEATURE2=VALUE2 ...
...
this mechanism also makes it possible for a user interface author to implement a subset of a protocol version by rejecting some features that are defined in that version; however, you should realize that engine authors are likely to code for xboard and may not be prepared to have a feature that they depend on be rejected

The red text is version 2 and the blue text is more recent, and possibly not supported by some older engine versions ..

[Evert]

I looked earlier and noticed this ...

option NAME[=VALUE]
This command changes the setting of the option NAME defined by the engine (through an earlier feature command) to the given VALUE.

and the Engine to Xboard section was looking promising until I got to the last paragraph

feature FEATURE1=VALUE1 FEATURE2=VALUE2 ...
...
this mechanism also makes it possible for a user interface author to implement a subset of a protocol version by rejecting some features that are defined in that version; however, you should realize that engine authors are likely to code for xboard and may not be prepared to have a feature that they depend on be rejected

The red text is version 2 and the blue text is more recent, and possibly not supported by some older engine versions ..

The two are unrelated.
If the interface doesn't support a feature, it should send a reject command to the engine.
The engine can define a number of options (through a feature option command) which will show up in the engine's options dialog box in the interface. When an option is changed there the interface sends an "option" command.