Winboard Forum

An agreed command is needed from the GUI or chess protocol to the engine that says "castling not allowed" for any type of variant, including standard chess. Unfortunately, the term "nocastle" has been reserved exclusively by Winboard for Shuffle chess without castling. Therefore, it seems appropriate to request an xboard protocol addition for a generic no castling allowed - any and all variants. The option could also be added to UCI protocol.

The discussion on no castling with Lary Kaufman can be followed here:

http://talkchess.com/forum3/viewtopic.p ... 65#p822345

That generic command already exists: it is called 'setboard'.

Set the castling field to '-' in the FE, and the GUI or engine will know that castling is not allowed!

H.G.Muller wrote:That generic command already exists: it is called 'setboard'.

Set the castling field to '-' in the FE, and the GUI or engine will know that castling is not allowed!

Of course. The user could create a file called "nocastle_standard.epd" with one entry:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w - - 0 1

then paste in the fen position for a game, or a file name for a match. This would be protocol type transparent. I like it, and fen substitution may be the best solution.

Can a game option be explored? Apparently there are custom options available in winboard which I do not fully understand, and have no success with. We could agree that it is undesirable to send undefined options to another engine. This could create undefined behavior. What would xboard do if it received a feature request from an engine? In C:

Code: Select all

printf("feature option=\"NOCASTLE -check value\"\n");

I suppose 'value' here is symbolic for 0 or 1.

On receiving that, XBoard would check if its -first/secondOptions (string) option for that engine would contain the text "NOCASTLE=value", and if it does, send this text up to the next comma to the engine as

option NOCASTLE=value

In all cases it will remember the engine has this option, and show it in the Engine Settings dialog as a checkbox, which is ticked according to the current 'value'. If the user alters the tick state there the same command as given above is used to send the new value to the engine.

H.G.Muller wrote:I suppose 'value' here is symbolic for 0 or 1.

On receiving that, XBoard would check if its -first/secondOptions (string) option for that engine would contain the text "NOCASTLE=value", and if it does, send this text up to the next comma to the engine as

option NOCASTLE=value

In all cases it will remember the engine has this option, and show it in the Engine Settings dialog as a checkbox, which is ticked according to the current 'value'. If the user alters the tick state there the same command as given above is used to send the new value to the engine.

The correct way to print the value was a little confusing. A clear example would makes things much easier than guessing. This printf seems to produce the correct box:

Code: Select all

printf("feature option=\"NOCASTLE -check 0\"\n");

If the box is ticked then it sends only to the first engine:

11057 >first : option NOCASTLE=1

else it prints in the debug file,

[x] NOCASTLE

Neither the GUI or the second engine have any idea what NOCASTLE means. However, option NOCASTLE may be of some use as a way to handicap the first engine, but special code has to be added to interpret the "option" sent. The exercise in very interesting as now I know how custom options work.

That is the idea of engine-defined options: only the engine that defines them knows what they mean, and hopefully the names are so self-explanatory that the user will know it too. They are mostly used for controlling stuff that is not of general use.

Handicapping an engine by not allowing it to caste can still be done by setting up a position with KQ or kq castling rights only. But then the opponent would know it too, so it is not quite the same. It seems a bit contrary to the nature of chess to have one player not know what the other can do.

In principe one could make all kinds of secret handicaps for one of the players. E.g. limit the range of Bishops or Rooks to some adjustable number below 7, or declare some of the squares forbidden for certain piece types.