ChessGUI and Chess960

[Matthias Gemuh]

ChessGUI is quite versatile in handling Chess960, ... but there are limits.

Some few engines seem to implement a new type of Shredder-FEN, which castles with "O-O" instead of the standard "King takes Rook".

ChessGUI will not support this new approach till its merits have been publicly discussed.

Sjaak seems to use this new approach.


Matthias.

[Evert]

Some few engines seem to implement a new type of Shredder-FEN, which castles with "O-O" instead of the standard "King takes Rook".

ChessGUI will not support this new approach till its merits have been publicly discussed.

King takes rook is not standard FRC castling under the XBoard protocol, see the description of the move format under GUI->engine communication listed here: http://www.gnu.org/software/xboard/engine-intf.html#8 It only lists O-O and O-O-O.

Note that the protocol description also says that the GUI is free to send castle rights as either KQkq or AHah (for instance) for FRC. The former currently doesn't work reliably in Sjaak (it only works correctly if the king and rooks are on their normal starting positions), which is indeed a bug.

[Modern Times]

I don't see any need to support that new approach. Chess960 standards already exist, why invent another one.

[Evert]

So explain to me how this is a "new" approach if the "old" approach is not documented in the XBoard protocol specification?

[Matthias Gemuh]

King takes rook is not standard FRC castling under the XBoard protocol, see the description of the move format under GUI->engine communication listed here: http://www.gnu.org/software/xboard/engine-intf.html#8 It only lists O-O and O-O-O.

Note that the protocol description also says that the GUI is free to send castle rights as either KQkq or AHah (for instance) for FRC. The former currently doesn't work reliably in Sjaak (it only works correctly if the king and rooks are on their normal starting positions), which is indeed a bug.

AHah is UCI and should go with UCI castling rules.

[Evert]

Sjaak is not an UCI engine.

The XBoard protocol states

In particular, in FRC or CRC, WinBoard will use Shredder-FEN or X-FEN standard, i.e. it can use the rook-file indicator letter to represent a castling right (like HAha) whenever it wants, but if it uses KQkq, this will always refer to the outermost rook on the given side.

so I fail to see how "AHah is UCI" is in any way true or relevant.

[Matthias Gemuh]

Sjaak is not an UCI engine.

It must not be an UCI engine to output "King takes Rook" in Chess960 mode.

If Xboard borrows AHah from UCI because of castling, it should not forget to take the UCI castling rules also.

[Matthias Gemuh]

ChessGUI is quite versatile in handling Chess960, ... but there are limits.

Some few engines seem to implement a new type of Shredder-FEN, which castles with "O-O" instead of the standard "King takes Rook".

ChessGUI will not support this new approach till its merits have been publicly discussed.

Sjaak seems to use this new approach.


Matthias.

I have not personally tried whether Sjakk really can't castle correctly under ChessGUI.
The problem was only reported to me.

Matthias.

[Matthias Gemuh]

I have not personally tried whether Sjakk really can't castle correctly under ChessGUI.
The problem was only reported to me.

Matthias.

Which version of Sjakk first supported Chess960 ?

[Evert]

If Xboard borrows AHah from UCI because of castling, it should not forget to take the UCI castling rules also.

Why?

Seriously, why?

Anyway, forget UCI. It's irrelevant because we're not discussing UCI engines here.

Sjaak is an XBoard engine. There is an XBoard protocol, which describes engine and GUI communication. I read the protocol and write my engine to follow that protocol as best I can (and there may be the occasional bug due to misunderstanding the protocol, which I should then fix). The protocol states "for FRC, either KQkq or AHah castling rules in FEN, and O-O and O-O-O as output for castling moves." So that's what I implement.

Your GUI doesn't understand O-O or O-O-O castling, but expects castling moves to be sent as KxR. This is not in the protocol. As far as I'm concerned, that's a bug in your GUI. I could work around it by having a special case KxR extension for castling moves. I could, but nothing in the protocol says I have to work around GUI bugs.

If I'm going to be nice and work around it, I would appreciate a more constructive attitude than "my GUI doesn't follow the protocol but is correct anyway because I say so and you have to deal with it".