ICS protocol question: FRC

[hgm]

Does anyone know how exactly an ICS encoded castling (and e.p.) rights int the game state it sends to the client (in board12 format)?

From looking at the WinBoard sources I can see that that they are transmitted as numbers directly after the board and stm character. But as WinBoard 4.2.7 does ignore castling and e.p. rights, it doesn't give me a clue how to interpret the numbers. From looking at some examples people have sent me over time for WinBoard_F debugging, I gather that the e.p. indicator gives the file number (a=0, b=1, etc) and -1 if no double move was played, and that castling rights are 0 (absent) or 1 (present) in normal Chess.

But how does it work for FRC? Somehow the Rook with which you can castle would have to be indicated, as later in the game there might be two Rooks on the side where castling is still possible. And after an under-promotion there might even be three!

[adams161]

hi,

Would sending you a debug file with some fr games be helpful?

Mike

[adams161]

offhand i think icc would send the castling rights in the initial fen and not update the rights but not sure on that.

[adams161]

i think winboard uses style 12.

this is the help file:

http://www.chessclub.com/help/style12

quoted from file:

The data is all on one line, e.g.:

<12> rnbqkb-r pppppppp -----n-- -------- ----P--- -------- PPPPKPPP RNBQ-BNR B -1 0 0 1 1 0 7 Quimbee Darooha 1 2 12 39 39 119 122 2 K/e1-e2 (0:06) Ke2 0

This always begins on a new line, and there are always exactly 31 non-empty fields separated by blanks. They are:

* The string "<12>" to identify this line.
* Eight fields of eight characters each, representing the board position.
The first 8-character field is rank 8, then rank 7, etc, regardless of whose
move it is.
* Color whose turn it is to move ("B" or "W")
* -1 if the previous move was NOT a double pawn push, otherwise the file
(numbered 0--7 for a--h) in which the double push was made
* can white still castle short? (0=no, 1=yes)
* can white still castle long?
* can black still castle short?
* can black still castle long?




mike

[hgm]

Yes, please, that would help. Actually ICS protocol is such that they send the full games state (includingboard position) on every move. But unfortunately not as FEN. So the initial position is not treated any different.

Try to make a game where you destoy castling rights one by one.

[adams161]

My last post were i included style 12 info i think will solve this issue for you.
Mike

[hgm]

The description of the command is what I figured out for normal Chess. But the problem I have is that this system is not ambiguous enough for FRC:

Later in the game there can be two Rooks on one side of the King, and it would somehow have to tell which of those two you can castle with. Of course make a convention where 'long castling' always refers to the left-most ('Q-side') Rook, but in theory there could be under-promotions, and you could have three Rooks. If I was in charge of the ICS protocol I would use codes other than 0 or 1 to indicate the Rook file (2=a, ..., 9=h). But they might also have adopted a work-around sending only the instantaneous castling possibility, (i.e. let the rights apply to the Rook closest to the King on the indicated side, knowing that you cannot castle with the other one on this move anyway, knowing that after the move they will send a new board).

So could you try to create two positions where there are two Rooks on the same side, where either the inner or the outer has castling rights, to see what it does then? (And perhaps one with 3 Rooks as well?)

[Harald]

I do not know what ICS does.

Perhaps this link can help: http://en.wikipedia.org/wiki/X-FEN

Or search for "X-FEN". And to make R. Scharnagl happy avoid "Shredder-FEN".

[hgm]

Unfortunately Chess servers do not send FENs. They have their own format.

The FEN controversy is unfortunate. The only recommendation I can make to programmers is to always accept both. It would require intentionally malicious programming not to do so anyway: you would have to write completely superfluous non-trival code to refuse Shredder-FEN input when it differs from x-FEN.

In WB protocol FENs only play a role in the 'setboard' command. In protocol 1 this command does not exist, and 'edit' is used to transmit positions to the engine. To use 'setboard' and raise the FEN issue you would have to explicitly enable it with the protocol-2 'feature' command. The logical solution to the FEN controversy would be to provide different flavors of the "setboard=1" feature, like "xsetboard=1" or "shreddersetboard=1" for engines that want to make 100% sure they will not be confronted with FENs of the type they abhor. Or even simply "setboard=2" for x-FEN and "setboard=3" for Shredder-FEN. And then have the engine test if the GUI accepts this setting, and if it does not, send "feature setboard=0" to force using the 'edit' command.

But all that would involve about 100 times more work for the engine programmer then simply accepting A-H for castling rights in any position. Not to speak of the GUI programmer. I really have no enthusiasm for doing extra work that just serves to cultivate a childish vendetta...

[smrf]

... I really have no enthusiasm for doing extra work that just serves to cultivate a childish vendetta...

If the struggle for compatibility is regarded to be such a thing, then the problems you are experiencing now probably are mature ubuntu.

It is alwas surprising, to read such unfounded hostilities. Bashing of somebody seems to have a higher importance to you here, than to have a closer look to the real matter.

Reinhard Scharnagl