Chess960 on my variant ICS!

[Michel]

You say the current h-rook was a-rook, but how an FRC-engine could know it?

It is specified in the FEN that the G-rook has castling rights. If it was the H rook then X-Fen would have specified it as K. But since it is not an outer rook you have to specify its file.

[hgm]

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.

The engine can know this from the castling rights: Gg. Those tell the engine that g-Rooks have not moved. Thus the h-Rooks must have moved, if the initial position was one of the 960 FRC positions. But there is no need for the engine to make that deduction: the only thing relevant for the engine is that it cannot use the h-Rook for castling, not even after 1. g2g4 ... 2. Rg3. And the FEN castling-rights tell it that.

That is the whole point. Baron does not understand the FEN.

Now if the castling rights for this position would not have been Gg but GHgh, there would have been something fishy. The FEN would say that both Rooks and King have not moved (or the rights would not have existed), but both Rooks are on the same side of the King. This is a valid FEN, but for a position that could not be reached from any of the 960 FRC opening positions.

[pijl]

There were several GUI's that implemented the winboard protocol with FRC, even though the official winboard versions never implemented it.
At least two that I'm aware of: Arena, and winboard_x with some additional changes that I've added to it.
The Baron has been playing FRC at ICC for a long time, using this winboard_x version, and before that I've used Arena as well.

Anyway, I'm tired of this discussion. If you want to break compatibility with older engines that's fine with me.
Richard.

[hgm]

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

I don't see any benefit in this: if engines understand X-FEN, they automatically understand Shredder-FEN, unless they are intentionally sabotaged. Why create a feature ihavesabotagedmyengine=1 if it is simpler to undo the sabotage then to print that? Or better yet, do not sabotage it in the first place, for a double time-saver!

The opposite would not automatically be true. To understand X-FEN is fundamentally more difficult. This is why I prefer to send Shredder FEN.

Again, it is only engines that understand neither Shredder nor X-FEN that cause trouble. And the trouble cannot be solved by having the engine tell that it understands neither, because what would the GUI have to send for castling rights then?

It is better if engine programmers would spend time on fixing their FEN reader, rather than on adding feature commands that solve nothing.

[hgm]

There were several GUI's that implemented the winboard protocol with FRC, even though the official winboard versions never implemented it.
At least two that I'm aware of: Arena, and winboard_x with some additional changes that I've added to it.

Well, the Arena implementation is still broken as we speak. Try the position given above with Arena, and it would not work for any engine...

The Baron has been playing FRC at ICC for a long time, using this winboard_x version, and before that I've used Arena as well.

I have never looked at this special Winboard_x version (which I was told could not play normal Chess anymore, which was unacceptable). But it is risky to assume that one implementation of a feature that is not strictly specified by the protocol would automatically carry over to other implementations.

Furthermore, it remains to be seen if the Winboard_x version you are talking about was not broken, but just got away with the fact that ICC is broken in the same way, and denies castling rights in most FRC games in the first place. Never sending any castling rights other than for the A and H file is a very efficient way to hide problems in engines understanding castling rights.

Does this Winboard_x + Baron combination allow O-O in the position given above? If the answer is "no" (and I already know it is...), it still means that at least one of them must be broken. And even if all other positions work correctly, it does not prove that the other is not...

Anyway, I'm tired of this discussion. If you want to break compatibility with older engines that's fine with me.
Richard.

As was shown above, this is not a matter of compatibility. It is a matter of flakey implementation. But if you want to have an engine that cannot correctly handle the position above, it's fine with me. Because there is nothing I could do to fix that in the GUI.

And the demand "keep the GUI broken, so that it can't expose that my engine is broken as well" just won't fly with me...

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

I don't see any benefit in this:

But Michel see it, and me too.

You should allow two FEN forms: X-FEN and Shreder-FEN, and let the rest to users and programers, to configure their engines for Winboard.

Compatibility should be maintained. Why do you insist in break it?

I am not talking now about engines bugs, but only about necessity to have two forms for FEN strings in Winboard.

SL

[hgm]

Name one of those benefits then, or consider that you might see it wrong!

For one, compatibilily is broken more badly by requiring engines to send a certain feature fentype=N, which existing engines certainly do not do yet, as it is by sending a single FEN type that almost all properly implemented existing engines will understand. You just hear Richard; he is adamant that he won't change anything in his engine, so he certainly won't add an xfen feature. (Which is not any more difficult than letting his engine understand A-H as castling rights, or simply ignore and assume castling rights ("if(variant=FRC) rights=ALL;" is all that is needed to fix his engine). Or even add a linefeed to his error message! So the peoposed xfen and shredder options would not make the slightest difference to The Baron, as he would not even sent them!

Problem is that a GUI does not have an oracle to tell it which engines are defective and which not. And requiring broken engines to send something to tell that they are broken has never been a succesful strategy, as programs are hardly ever broken intentionally. So when an author would discover his engine is broken, he would fix it, rather than change it to send the "IamBroken" message.

And even if the GUI would receive the "IamBroken" message, what could it do? The broken engines would understand neither X-FEN nor Shredder-FEN. So what would you propose to do, when the engine reports feature xfen=0 shredder=0 that would produce any benefits?

So the logical solution is that the user should replace the oracle, and tell the GUI which engines are broken. Providing a command-line option to specify the castling field (not only telling that the engine is broken, but also handing the work-around) seems a very effective solution for that.

I think it is in general very bad strategy to formalize ways of letting

[Michel]

So the logical solution is that the user should replace the oracle, and tell the GUI which engines are broken. Providing a command-line option to specify the castling field (not only telling that the engine is broken, but also handing the work-around) seems a very effective solution for that.

Sending X-fen seems much more effective to me as this is what older engines will likely default to (even if their implementation is slightly broken in a practically completely irrelevant way).

But you have obviously made up your mind that the user should be punished for "using a broken engine" so there is no point in continuing this discussion.

[slobo]

Compatibilily is broken more badly by requiring engines to send a certain feature fentype=N, which existing engines certainly do not do yet, as it is by sending a single FEN type that almost all properly implemented existing engines will understand.

Problem is that a GUI does not have an oracle to tell it which engines are defective and which not. And requiring broken engines to send something to tell that they are broken has never been a succesful strategy, as programs are hardly ever broken intentionally. So when an author would discover his engine is broken, he would fix it, rather than change it to send the "IamBroken" message.

And even if the GUI would receive the "IamBroken" message, what could it do? The broken engines would understand neither X-FEN nor Shredder-FEN. So what would you propose to do, when the engine reports feature xfen=0 shredder=0 that would produce any benifits?

So the logical solution is that the user should replace the oracle, and tell the GUI which engines are broken. Providing a command-line option to specify the castling field (not only telling that the engine is broken, but also handing the work-around) seems a very effective solution for that.

Harm, for me it is the same problem as
"fischerrandom"="Fischer Random"="Chess960"="Chess 960"

You should allow synonyms in a Universal Winboard.

I doubt you want a Winboard only for Fairy-Max.

[hgm]

But you have obviously made up your mind that the user should be punished for "using a broken engine" so there is no point in continuing this discussion.

I think you see that wrong: I want to help the user by making him aware that the engine is broken. Are you also of the opinion that C-compiler writers want to "punish" their users for making errors by sending "undeclared variable" error messages? I am sure that programmers would have far fewer error messages from there programs when this error message was completely surpressed...

I think it is a very bad strategy in general to cater to broken implementations and try to hide their errors, if you cannot totally eliminate them. It will only lead to the emergence of more broken engines, and degenracy of the standards. And create a general environment where nobody can rely that their engines would work in exceptional situations.