Chess960 on my variant ICS!

[hgm]

OK, Baron is obviously broken: It unjustly refuses the setup of the initial position, and then it forgets to print a newline after the error message, so that the pong response to an earlier ping is lost (it becomes part of the error message), and a deadlock occurs as WinBoard keeps waiting for the pong.

[pijl]

112656 >first : setboard nqrknrbb/pppppppp/8/8/8/8/PPPPPPPP/NQRKNRBB w FCfc - 0 1

This fen string is illegal in earlier (the 'Mann') versions of the winboard protocol and is refused by the Baron.
Richard.

[pijl]

OK, Baron is obviously broken: It unjustly refuses the setup of the initial position, and then it forgets to print a newline after the error message, so that the pong response to an earlier ping is lost (it becomes part of the error message), and a deadlock occurs as WinBoard keeps waiting for the pong.

The Baron is compliant with earlier versions of the winboard protocol. It does not accept the UCI type of FRC fen. So sending the setboard command with the regular kqKQ type of castling rights fixes the problems.
You're correct about the newline that is missing, but as this codebase is ancient I'm not going to fix it.
Richard.

[hgm]

The "earlier version" of the protocol does not specify which type of FRC FEN should be used (XFEN or Shredder) at all. It refers to the FEN definition to the official PGN standard, which only defines a FEN format for normal Chess, and leaves the definition of FEN for Chess960 totally open.

But whatever you might argue about standards: fact remains that Baron cannot handle the position

[D]2k3rr/1pppppp1/8/7p/7P/8/1PPPPPP1/2K3RR w Gg - 0 1

(see the other thread), and will refuse a O-O move after loading this position, under any existing GUI. So the implementation of its setboard command is broken. That (some far-fetched interpretation of) a protocol forces you to make broken implementations does not mean that this implementation is less broken.

So as long as Baron cannot handle the above position, it is broken...

[pijl]

The "earlier version" of the protocol does not specify which type of FRC FEN should be used (XFEN or Shredder) at all. It refers to the FEN definition to the official PGN standard, which only defines a FEN format for normal Chess, and leaves the definition of FEN for Chess960 totally open.

But whatever you might argue about standards: fact remains that Baron cannot handle the position

[D]2k3rr/1pppppp1/8/7p/7P/8/1PPPPPP1/2K3RR w Gg - 0 1

(see the other thread), and will refuse a O-O move after loading this position, under any existing GUI. So the implementation of its setboard command is broken. That (some far-fetched interpretation of) a protocol forces you to make broken implementations does not mean that this implementation is less broken.

So as long as Baron cannot handle the above position, it is broken...

The older specification did define how winboard should interface with the engines. For that purpose there was a variants string and a definition of the castling move. It did not specify a new different type of FEN, meaning that the old FEN should be interpreted.
That works in > 99.999% of the cases where you would want to send a position to the engine, and it works in 100% of all start positions. Now you've replaced it by something that works in 0% of the cases for the older engines. That's progress. So your winboard has broken the older specifications.
Anyway, it will not work in the Baron 1.x nor in the Baron 2.x. I'm not going to fix it either as work on that code base has been terminated.

In the Baron 3.x it will work in winboard by coincidence as it shares the FEN interpreter with the UCI version where the aAgG type of castling rights are legal. But I'm not planning to release that yet.
Richard.

[hgm]

Where are these old specifications you are talking about? I am only aware of these on Tim Mann's website, and it does not specify anything for how to send Chess960 castlings.

I have not altered these specs in any way; my version of the protocol specs still leaves the format of the Chess960 FEN undefined. It only mentions that explicitly, while the oldest version I know only did it implicitly, by omission. I can add that it has always been Tim Mann's intension that Shredder FEN should be sent: the protocol-3 draft specifies this explicitly. The only reason it was omitted in his v2 specs is presumably that his versions of WinBoard did not implement FRC at all.

I don't even specify that for variant xiangqi you have to use a FEN with xiangqi pieces in it, and for capablanca you need a FEN with a 10x8 board. This because I would expect people to have the good sense to make their engines understand FENs that belong to the variant the engine is designed for. Or should I make a disclaimer similar to those made by car navigation systems: "if the system say 'turn right', but there is no bridge, so you drown in the canal, we cannot be held responsible"...

[pijl]

Where are these old specifications you are talking about? I am only aware of these on Tim Mann's website, and it does not specify anything for how to send Chess960 castlings.

From the spec:
MOVE
See below for the syntax of moves. If the move is illegal, print an error message; see the section "Commands from the engine to xboard". If the move is legal and in turn, make it. If not in force mode, stop the opponent's clock, start the engine's clock, start thinking, and eventually make a move.

When xboard sends your engine a move, it normally sends coordinate algebraic notation. Examples:

Normal moves: e2e4
Pawn promotion: e7e8q
Castling: e1g1, e1c1, e8g8, e8c8
Bughouse/crazyhouse drop: P@h3
ICS Wild 0/1 castling: d1f1, d1b1, d8f8, d8b8
FischerRandom castling: O-O, O-O-O (oh, not zero)

Richard.

[hgm]

None of what you quote has changed. WinBoard 4.3 does all that exactly as specified. But there is no mention of FEN and castling rights at all... And this is where Baron fails.

[Michel]

It seems to me that since X-FEN existed before Shredder FEN Winboard could well send
X-FEN instead of Shredder FEN to be friendly to older engines which are more likely to support the former variant.

[hgm]

This is why I left it explicitly undefined in the protocol specs what FEN would be sent: so that GUIs can pick whatever works best.

But your argument in so far is invalid that it is not the engines that are using X-FEN because they are so old that it was the only existing standard that are treated unfriendly. If they understand X-FEN, they almost certainly will also understand Shredder-FEN. X-FEN uses A-H and a-h castling notaition as well, in many positions.

It is only the engines that have chosen a flakey implementation of their FEN reader, and at the same time feel they should be pedantic about it, that get into trouble. If you make the design choice to make a flakey castling-rights reader, on the assumption that you only want your engine's setboard to work for opening positions, you should do as protocol-1 engines and assume all castling rights always exist. And if you find something in the castling field you don't understand, shut up in shame and pray you get away with your guess.

The claim that "the FEN string was illegal in the earlier version of the protocol" is so far unsubstantiated, and likely plain wrong. There is thus no basis for an error message at all, especially since an error message in this situation never solves anything but is a 100% guarantee of ending the game by forfeiting on time.

The main consequence of what you propose is that broken implementations might work more often, so that it can stay hidden longer that they are in fact broken. I have my doubts if this is an advantage, as at some point the fact that they are broken will come back in an inopportune moment to bite the unsuspecting user.

I think it is a legitimate requirement for an engine that plays a certain variant to understand the FENs that are customarily used in that variant. So I'd rather use a command-line option to flush out the broken engines quickly, while at the same time making it possible for the user to still play them (but be forewarned about their defects). Something like /firstEngineFlakey or /secondEngineFlakey...