Chess960 on my variant ICS!

[Michel]

It seems The Barron has a bug in its X-FEN parsing. But this is very hard to trigger in actual play. Bugs in software in rare situations is unfortunately not uncommon. But we are used to it.

If xboard sent X-FEN instead of Shredder FEN (on the grounds that this is the older standard) users could simply enjoy their game of FRS without probably ever encountering this bug. I would assume the same goes for many older engines.

Engines that want shredder fen could perhaps send feature shredder=1?

[slobo]

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...

If Baron refuses that position for castling, it is correct, because in the starting position King must be between two rooks. If it is not between them it means pieces have already played their moves and in such a condition the castling is not possible.

Harm, Winboard should be developed in the direction of more flexibility, not in the opposite one.

So, my proposal is to allow two option for starting FEN string:

X-FEN option, and Shredder-FEN option.

Regards.

[hgm]

This is a bit like discussing programming languages, wheter it is better that variables should be declared or not. FORTRANners always ridicule ALGOLists, for wasting time on declaring all the variables. And then spent hours on debugging their own programs, because they misspelled a variable name somewhere. (Especially the O <->0 typo worked wonders on most line printers. )

In analogy, I would like to be pointed out as quickly as possible that a certain engine is fundamentally defective. (As I added later to my previous post, so you might have missed it. ) Then I can gamble on that in practice it might still be able to do what I want it to do as a concious decision. This is why I would rather solve it through a command-line option, which needs user-intervention, that through some automatic feature mechanism.

[pijl]

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.

It does specify how to send fischerandom castlings. It does not specify a different type of FEN though. This leads to:
- It should be possible to play a fischerandom game according to the old specifications, which uses the old (regular) FEN.
- If you add something to the protocol, you should enable it using a feature command. This is obviously not done here so you cannot assume that an older engine understands a new way of sending the position.
Richard.

[slobo]

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.

Harm, from the chronological standpoint, the problem is with the new, Shredder, FEN format. But I am a user. For me it does not matter what is correct what is not. For me all these rules are conventions. So let´s make winboard the most flexible possible.

Gens una sumus regards.

SL

[hgm]

If Baron refuses that position for castling, it is correct, because in the starting position King must be between two rooks. If it is not between them it means pieces have already played their moves and in such a condition the castling is not possible.

This is wrong. Only the h-Rooks have been played here (as the castling right for H-side castling indicates), e.g. through Rb1-a1-a3-h3-h1. So neither King nor g-Rooks have moved, and castling rights are fully in tact.

That Baron refuses the castling shows only one thing: that it is broken.

But I am not against options to provide broken engines to function through a kludge. So I will probably provide an option to force castling rights in all FENs send to the engine to any user-given string. So people could run defective engines like Baron through /firstForceCastlingFieldFEN="KQkq". This could at the same time be used to fix broken Xiangqi engines that expect castling and e.p. fields in their FENs: /firstForceCastlingFieldFEN="- -".

[Michel]

I still think it is nicer to send X-FEN by default (as it is the oldest standard).

Newer engines can send

feature shredder=0/1
feature xfen=0/1

to announce that they do or don't understand certain castling rights conventions.
This is similar to "feature san=1" etc...

[slobo]

If Baron refuses that position for castling, it is correct, because in the starting position King must be between two rooks. If it is not between them it means pieces have already played their moves and in such a condition the castling is not possible.

This is wrong. Only the h-Rooks have been played here (as the castling right for H-side castling indicates), e.g. through Rb1-a1-a3-h3-h1. So neither King nor g-Rooks have moved, and castling rights are fully in tact.

That Baron refuses the castling shows only one thing: that it is broken.

But I am not against options to provide broken engines to function through a kludge. So I will probably provide an option to force castling rights in all FENs send to the engine to any user-given string. So people could run defective engines like Baron through /firstForceCastlingFieldFEN="KQkq". This could at the same time be used to fix broken Xiangqi engines that expect castling and e.p. fields in their FENs: /firstForceCastlingFieldFEN="- -".

I think you are wrong, Harm. You say the current h-rook was a-rook, but how an FRC-engine could know it? It is also possible that the current h-rook was h-rook from the beginning and that it played only h1-h2-h3-h1. In this case Baron refuse an illegal position.

[hgm]

- If you add something to the protocol, you should enable it using a feature command. This is obviously not done here so you cannot assume that an older engine understands a new way of sending the position.
Richard.

That feature already exists: setboard=1. If your engine cannot understand FENs, it should not send setboard=1. Then WinBoard will enter the position throught the edit command, and you should assume you have castling rights.

Your claim that there was an old way to send the position is factually inaccurate: No WinBoard I have seen ever sent the opening position to the engine. This is why FRC never worked. Except in ICS mode, where the problem did also not occur, as ICC only grants castling rights to corner Rooks and central Kings, even in FRC.

Basically you are trying to argue that there is no need for an FRC engine to understand FRC FENs.

[slobo]

I still think it is nicer to send X-FEN by default (as it is the oldest standard).

Newer engines can send

feature shredder=0/1
feature xfen=0/1

to announce that they do or don't understand certain castling rights conventions.
This is similar to "feature san=1" etc...

It seems logical to me.