ChessGUI and Chess960

[Evert]

Sjaak /= Sjakk.

Sjaak has supported FRC (and CRC) since revision 399, late November 2011. Note that I don't really play either of those, which also explains why there is a bug in parsing the FEN that I wasn't aware of until now. It happened to work with those few positions I tested with.

[Matthias Gemuh]

... nothing in the protocol says I have to work around GUI bugs.
...

You really don't have to. Just do what you feel is right.

Matthias.

[hgm]

XBoard protocol has specified castling should be sent as O-O and O-O-O since long before ChessGUI even existed. (Only the requirement to understand the letters A-Ha-h in FEN, or in general any FEN notation that is common in the current variant was added by me.) It would be sad if ChessGUI adopted a policy to be intentionally non-compliant.

In the interest of avoiding chaos that can serve no one, I would advice any engine author against catering to GUI bugs. Especially if doing so would compromise his engine for running with compliant software. There is no guarantee WinBoard or any other WB-compatible GUI will ever support KxR notation.

Just as I would advice GUI authors against catering to non-compliant engines. For historic reasons WinBoard already does way too much of that.

[Matthias Gemuh]

XBoard protocol has specified castling should be sent as O-O and O-O-O since long before ChessGUI even existed. ....

... but AHah was borrowed long after the ChessGUI project had begun.

[hgm]

Not sure what you want to say with that. Using the file letters in the castling fields of FENs has been standard in FRC ever since FENs were used for FRC. Unfortunately there are two competing standards, and WB protocol does leave it to the GUI designer which one he prefers to use. (As it is not an extra burden one the engine author to understand both.)

[Evert]

(As it is not an extra burden one the engine author to understand both.)

Yes it is!

Supporting KQkq in addition to AHah means I have to teach Sjaak what a rook is (as opposed to saying "castling is a move between a king and whatever piece is on square x", which is how it's currently implemented and which only works in FRC if king and rooks are on their normal squares). It's more of a hassle, but it's clear how to fix it, I just need to get down to doing it. I will fix it for the next release.

Aside from that, I really don't care who implemented what first or whether UCI did something in a certain way before XBoard protocol did it slightly differently...

[hgm]

OK, I stand corrected. This is a bit of an unusual implementation, though. Most engines just use the castling field to set the permission flags, not to tell the engine how to perform castling.

Beware that in Seirawan Chess we extended the castling field to become a 'virginity field', so that in the opening position it would have value HGFEDCBAhgfedcba (Shredder FEN) or KGFDCBQkgfdcbq (X-FEN). So in Seirawan960 you could not use your method to determine what the Rooks are anyway!

[Evert]

OK, I stand corrected. This is a bit of an unusual implementation, though. Most engines just use the castling field to set the permission flags, not to tell the engine how to perform castling.

Most engines are not general variant engines.
I didn't originally design Sjaak with FRC in mind, so I just defined castling as with king and "corner piece" and hard-coded the various masks that have to be checked. When I extended to boards larger than 8x8 I wrote a function to derive the castle flags from the position of the king and the initial position of the "rook", which is the origin of the "castling is a move of a king with some other piece on square x" semantics.
Once I had that it was actually easy to implement castling for FRC (it may be true that I had CRC before FRC). As far as Sjaak is concerned there is only one unusual piece, namely the king. All other pieces are treated equal (except it has some heuristics to designate one of them as a "pawn").

Beware that in Seirawan Chess we extended the castling field to become a 'virginity field', so that in the opening position it would have value HGFEDCBAhgfedcba (Shredder FEN) or KGFDCBQkgfdcbq (X-FEN). So in Seirawan960 you could not use your method to determine what the Rooks are anyway!

Good thing Sjaak doesn't play Seirawan chess and Leonidas doesn't play FRC then.
Although Leonidas can't currently handle those extra flags in the castle field anyway; now that I know how it was finally implemented (I remember the discussion, just not the conclusion) I'll get it fixed.

[Modern Times]

There are a number of Winboard engines that do play FRC perfectly under ChessGUI, for example

Amyan
Betsy Fischer
Danasah
EXchess
Frenzee
Jonny
The Baron

I guess they took different choices to implement castling.

[TonyJH]

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

That doesn't make any sense. Why should XBoard protocol be obligated to use UCI's protocol for castling moves, just because of the FEN format being used? Those are two different things.

Regardless of whether some engines work and some don't with this implementation, ChessGUI isn't implementing XBoard protocol correctly.