Why to use compatible X-FEN (in Chess960)

[Reinhard Scharnagl]

There seems to be a need to replace some unqualified statements arising in some
fora to FEN compatibility according Chess960 by something more objective.

There are people requesting a compatibility of Chess960 and traditional chess in
both directions. But that is obviously nonsense, because in Chess960 positions
exist with castling rights never occuring in common games. And there are people
thinking this discussion would be a question of winning a battle, whereas in
fact this is a big endeavor to preserve compatibility, keeping Chess960 what it
is: a compatible superset to traditional chess.

Thus, because Chess960 is bigger, full compatibility means:

A) Any possible situation has to be uniquely encoded (that is: any position,
which also exists in traditional chess, has to be 100% identically encoded like
done in already used FEN). (P.S.: This also is necessary in respect to the PGN
specification requiring a uniquely encoding of games and thus of FEN strings.)

This is done by X-FEN but not yet by Shredder-FEN, concerning positions with
castling rights only related to traditional K-R placements, e.g. SP 518, which
is the usual starting array of traditional chess. Also 18 pseudo-FRC starting
positions (having R-K-R placed at traditional positions) are affected and a
numberless set of additionally thinkable positions.

B) The outer form of created FEN strings should look like traditional FEN.

Taking all 960 starting arrays of Chess960 as an example X-FEN uses 'KQkq' in
every case to encode existing castling rights, whereas Shredder-FEN still
produces a set of very different and strange looking castling tags. This is
related to not using X-FEN's well established assumption that castling rights
by default are related to the outermost rook of an affected side.

C) Chess960 games already stored in databases, used Chess960 representations
in online chess servers, the ability of PGN viewers already enhanced to also
display Chess960 PGNs, and a lot of existing GUIs and applications should be
kept working instead of being devaluated.

Because X-FEN is the base of all those approaches, Shredder FEN actually is
disturbing those pioneer activities without any need. To preserve compatibility
instead should have priority number one.

I warmly recommend Shredder to also support X-FEN
http://www.chessbox.de/Compu/fullchess5b_e.html instead of its incompatible
approach still blindly ignoring current activities to compatibly support Chess960.

(P.S.: X-FEN formerly has been known also as FRC-FEN.)

Regards, Reinhard.

[Reinhard Scharnagl]

Hi friends of Chess960 !

To show my flexiblity during the talks with SMK, before he released the new Chess960 enabled and very welcomed approach of Shredder, could be well documented by my following proposal to be discussed that time, which nevertheless has been immediately refuted:

Take the Shredder FEN, but if there would be Rooks with castling rights placed at a corner, then use a tag from "KQkq" instead of "AHah".

It is obviously, that this proposal would have been simply to be implemented and as well would have lead to UNIQUE FEN-STRINGS, thus clearly leading to an enhanced compatibility to existing FENs and PGNs.

Nevertheless this proposal would have affected existing applications and stored games, but for sure it would have been better than that, what has been released then with new Shredder FRC's own FEN encoding.

But another proposal would have made much more sense even than the above one, to use "KkQq" as long as the affected Rook would be the outermost one of the affected side.

But - I am very sorry - there has been no movement at all at SMKs side.

Reinhard Scharnagl.