Arena 2.4.0...

[Engin]

since along years Arena didnt send correct chess960 FEN to the engines with the standard "HAha" format, insteed its send false "KQkq" in the fen string of start position.

Other GUI like Shredder Classic and even the Chess GUI support very good all castle rules and FEN formats

its not really possible for many UCI engines to play Chess960 under Arena, the only one tricky is to using the polyglot adapter that send between engine and GUI the stardard castle and FEN formats.

i wish that this will be fixed soon to play normaly Chess960 under Arena, i like Arena too but i dont like to play chess960 under Arena, prefer like Chess GUI that support very good and correct Chess960 castle moves

the other is what i dont like is that Arena remove the swiss pairing system, that was implement in provous versions, but removed after 2.x version ?
why not implement a better swiss pairing system ?
you know that are over 1000 engine are existing todays ?
it is not possible make a round robin with 1000 engine in one tournament, you must split the tournament in divisions, but i will to play all engines in one tournament like in human open tournament everywhere are using.

ok...that are to much text....sorry

[Engin]

.... i forgot a other bug to tell you with the not correct notice time losing of engines with for example 1+0 or 1+1 , arena didnt released which engine had losed on time correctly, if white as losed on time its give the point for white 1-0? and if losed black gives the point to black 0-1 ??

please correct this bug too

[Engin]

can i get a beta version too for testing ??

[Alexander Schmidt]

since along years Arena didnt send correct chess960 FEN to the engines

Sorry Engin, Arena was the first UCI GUI to support FRC. At that time there was nothing like a "correct FEN". Arena made a new standert, the others used something else.

So it is not a bug, but a feature

To make the mess complete HG Müller changes something in the Winboard FRC protocol in his new Winboard version. So we have now 4 different FRC protocols...

[hgm]

Arena did not set a new standard, because the way it treats FRC FENs was broken from the beginning, and is even broken today. I hope at least that we agree that it is a bad idea to elevate something that does not work to a standard, so that now everyone will start making things that do not work...

WinBoard protocol did not support FRC castling rights at all, (or in fact any castling rights). There existed a proposal for a version 3 of the protocol (some features of which are implemented in Arena, btw), which did also define the FEN format for FRC. I did simply stick to that proposal, which was compatible with the UCI FEN standard.

So I don't feel I "changed something". WinBoard 4.2.7 did not support FRC (except in ICS mode, where it was just displaying the boards the ICS sent it, and anything would work). I made WinBoard support FRC, and of course I did it according to the pre-existing protocol definition. Which, unlike what Arena does, actually will lead to fully correct operation (which is, of course, why it was suggested as a standard). Especially since at the time I did it, Chess960 had matured and did have FEN standards adapted to that variant.

For those not aware of the problem: set up the following positions:

[d]3r2k1/b2qppp1/7p/8/8/6P1/4PP1Q/4KR1R w F 0 1

and try if an engine can find the solution for the mate threat 1... Qd1#.

Note, btw, that WinBoard still fully supports engines that have a broken FRC FEN implementation: there are the options

/firstNeedsNoncompliantFEN="KQkq -"
/secondNeedsNoncompliantFEN="KQkq -"

with which you can force WB to send predefined castling and e.p. fields irrespective of the true casling rights (like WB 4.2.7 did).

[OliverUwira]

Arena did not set a new standard, because the way it treats FRC FENs was broken from the beginning, and is even broken today. I hope at least that we agree that it is a bad idea to elevate something that does not work to a standard, so that now everyone will start making things that do not work...

The Arena FRC implementation is not necessarily broken. Castling rights as KQkq is correct in X-FEN, which does only send them as HAha if there is ambiguity (as in Ra1, Rb1, Kg1 where the queenside castling rook is the Ra1 and the kingside castling rook came to b1 via some route).

I never came around manifacturing a game that leads to a situation like that in order to see whether it is really X-FEN what Arena is sending, but I'm also not a beta tester for what it's worth.

On the other hand, the position setup dialog does never offers anything else than KQkq, so that one can't construct a test position for the scenario above. THIS is most definitely not a feature, but a bug, because it excludes a whole class of FRC positions from being set up via FEN.

The GUI board also has a quirk, because it sometimes freezes when you attempt to enter a FRC castling move by dragging the king onto the corresponding rook. Also not a feature.

All of this is regarding Arena 2.0.1.

[hgm]

The Arena FRC implementation is not necessarily broken.

If with "not necessarily broken" you mean "sometimes it might still work", I guess we agree. But the WinBoard standards for "broken" are that we consder it boken when it does not _always_ work.

Castling rights as KQkq is correct in X-FEN, which does only send them as HAha if there is ambiguity (as in Ra1, Rb1, Kg1 where the queenside castling rook is the Ra1 and the kingside castling rook came to b1 via some route).

The rationale for letting WB send HAha (i.e. Shredder FEN) was that to make it always work, the engine would have to understand file notation anyway, even with X-FEN. Making it support X-FEN as well is just an unnecessary burden on the engine programmer, who now has to provide code to figure out which Rook is the outer one if he encounters KQkq. He will still encounter KQkq in variant normal, of course, but these could be handled by simply fixing Q=A and K=H or J. Given that you have to understand B-G anyway in some positions, making it such that these would not work when they refer to an outer Rook would still require additional code, which serves no purpose other than intentionally causing a malfunction in a situation that would otherwise have worked flawlessly. I.e., it is sabotaging your own engine, and I don't see any reason for accomodating people that do such things.

For engines that are not interested in setting up positions other than an initial position, forcing the rights to KQkq always is an effective solution.

I don't know much about Arena, but can't you set up positions by pasting a FEN into it? In WinBoard you can do that, and you can give any castling rights with it that you want (as WinBoard does support both Shredder FEN and X-FEN in any variant), as well as holdings contents (for Crazyhouse/Bughouse).

[OliverUwira]

The Arena FRC implementation is not necessarily broken.

If with "not necessarily broken" you mean "sometimes it might still work", I guess we agree. But the WnBoard standards for "broken" are hat we consder it boken when it does not _always_ work.

Well, I meant that there is a _slight_ chance that Arena has correctly implemented X-FEN. That's not the case, however (see below).

Castling rights as KQkq is correct in X-FEN, which does only send them as HAha if there is ambiguity (as in Ra1, Rb1, Kg1 where the queenside castling rook is the Ra1 and the kingside castling rook came to b1 via some route).

The rationale for letting WB send HAha (i.e. Shredder FEN) was that to make it always work, the engine would have to understand file notation anyway, even with X-FEN. Making it support X-FEN as well is just an unnecessary burden on the engine programmer, who now has to provide code to figure out which Rook is the outer one if he encounters KQkq.

For engines that are not interested in setting up positions other than an initial position, forcing the rights to KQkq always is an effective solution.

I never liked X-FEN, because I'm with you that it's unneccesarily complicated. I remember the discusssion about it when I started working on Kurt in 2006. The idea was not to break with standard FEN if not absolutely necessary. But you could never support FRC correctly if you didn't implement file notation, so I never saw the point of X-FEN.

It is true that KQkq is enough for all 960 starting positions, but you could never include positions from FRC games that have this "intermediate rook" into EPDs and the like.

I don't know much about Arena, but can't you set up positions by pasting a FEN into it? In WinBoard you can do that, and you can give any castling rights with it that you want (as WinBoard does support both Shredder FEN and X-FEN in any variant), as well as holdings contents (for Crazyhouse/Bughouse).

You can set up a position by pasting a FEN from the clipboard. But there's also a board setup dialog. This dialog has checkboxes for white and black castling rights, long and short each.

As far as I'm aware, those will always make Arena send an FEN string with KQkq rights, such as here (I'm envisaging the Ra1 to be the castling rook, while the Rb1 came there like Re1-e4-b4-b1). If you then copy the FEN to the clipboard you get this:

Code: Select all

5rk1/pp3r1p/2p3p1/5b2/2N2P2/3P2P1/P1P4P/RR1K4 w Q - 0 1

I've set white's castling long rights. There's no way to specify further.

[Michel]

I may implement FRC in GnuChess.

Question: Does Arena follow the K takes R convention in FRC?

It didn't seem to understand this in normal chess (which is of course is perfectly fine as it is not the standard castling notation).

[luisrodg]

Not sure if I should post this here but, on Arena 2.0.1 im playing a computer account on a chess server and I have "Accept challenges automatically" checked on the options but it doesnt work. People match me but Arena doesnt auto accept?

Any help?