Chess960/FRC games use KQkq castling notation in the analysis board, which is ambiguous.

[AndyGrant]

Exact URL of where the bug happened

https://lichess.org/1wY79tl7

Steps to reproduce the bug

Observe the post-game analysis via https://lichess.org/1wY79tl7/white#17

The final position lists the FEN as rkbnrqnb/8/8/pppppppp/PPPPP3/B7/5PPP/1KRNRQNB b Kkq - 1 9 in the Share & Export tab. This fen is ambiguous without the context of the previous moves. It is unclear whether or not White may castle with the c1 or the e1 rook, as you cannot tell which rook started on a1.

( If you want to be REALLY picky, you can tell, because black never moved either rook. But if Black moved both rooks, then you would be truly SOL on figuring out which rook you could castle to )

What did you expect to happen?

The notation should be in the shredder format, AHah, to ensure correctness as a stand-alone FEN.

What happened instead?

The notation used KQkq, which is only valid for FRC for the starting position.

Operating system

Windows 10 (N/A)

Browser and version (or alternate access method)

Chrome 26.0.6478.182 (Official Build) (64-bit)

Additional information

No response

[tsoj]

And even if there is some ruleset that makes the decision process unambigious, it is still better to use the shredder format, since most chess tooling relies on that and will fail when being confronted with FENs like rkbnrqnb/8/8/pppppppp/PPPPP3/B7/5PPP/1KRNRQNB b Kkq - 1 9 including chess engines using the Lichess BOT API.

[TBestLittleHelper]

Lichess actually uses x-fen, thus the rule that applies should be https://en.wikipedia.org/wiki/X-FEN#Encoding_castling_rights and this should resolve any ambiguety. ( ie. a fen like this : rk2rqnb/1b6/2n5/pppppppp/PPPPPP2/B1NQ4/6PP/1K2RRNB w Ek - 8 14 )

I am curious, what spesific chess engine and toolig that relies on SMK-FEN instead?

[tsoj]

For example Caissa. If you enter 1rrk1bnn/8/q3b3/pppppppp/PPPPPPPP/Q3B3/8/1RRK1BNN w Bb - 10 14 and 1rrk1bnn/8/q3b3/pppppppp/PPPPPPPP/Q3B3/8/1RRK1BNN w Qq - 10 14, you'll get only for the Bb variant the correct perft result. The same happens for Stormphrax and Clover.

Or Viridithas, which works fine with the Bb variant, but crashes with

setoption name UCI_Chess960 value true
position fen 1rrk1bnn/8/q3b3/pppppppp/PPPPPPPP/Q3B3/8/1RRK1BNN w Qq - 10 14

[nocturn9x]

To add context to this issue: having to deal with this kind of behavior is really annoying and was the source of many problems for heimdall because Lichess is not at all consistent with the way it sends castling moves or FENs, meaning that you need a bunch of workarounds to support both shredder notation, standard chess and whatever variant Lichess came up with

[AndyGrant]

I suppose this is not a bug then. Just confusing because the use of X-fen is not overtly clear.

"Kk" identifies the ability of g-castling (or i-castling in 10×8 Chess), and "Qq" indicates c-castling (uppercase for White and lowercase for Black). The new and crucial point of the arrangement is that the castling rights provided by this as default are related to the outermost rook of the affected side. If instead an inner rook is associated with that right, the traditional castling tag will be replaced by the file letter of the involved rook, using upper case for White.

I would still use Shredder Notation personally, but that is just me. I know from reading many engines that almost none of them expect X-fen. Notably, I believe Komodo/Dragon actually expects the opposite of X-fen!

[kraktus]

Stockfish support x-fen which is the most important. X-fen has backward compatibility for standard chess which mean all guis not supporting shredder works.

For niche engines I think the best is to convert it to shredder before feeding it to them.