An FRC compatible xboard (sort of)

[Reinhard Scharnagl]

Volker,

I fully agree with your red quote.

Reinhard.

[Fabien Letouzey]

Hi all,

Since XBoard-960 is mentionned again.

I think I introduced a bug when converting "O-O"-like input into the internal KxR representation. This should be located in the parser.l file (which is Lex-compiled into parser.c).

The bug is that the farther-away rook is selected whereas it should be the closest to the king. Of course in practice it is unlikely to happen (one rook going to the other side, 1st rank).

Sorry for that ...

Fabien.

[Volker Pittlik]

...I think I introduced a bug when converting "O-O"-like input into the internal KxR representation. This should be located in the parser.l file (which is Lex-compiled into parser.c).

Sorry I don't understand that. I have no idea neither what the parser.l file contains nor what a Lex-compilation is.

The bug is that the farther-away rook is selected whereas it should be the closest to the king. Of course in practice it is unlikely to happen (one rook going to the other side, 1st rank)...

Isn't it pure convention which rook is selected? Whenever there are two rooks in the same direction in an FRC startup position the castling rook may be the rook closer to the king or the other one. (If there are more than two it is even more confusing.)

After Tord's clarification my engine assumes that the outermost rook is the one involved in castling. It is important that engine and GUI don't get out of synchronisation.

Regards

Volker

BTW: Good luck in Reykjavik!

[Fabien Letouzey]

Sorry I don't understand that. I have no idea neither what the parser.l file contains nor what a Lex-compilation is.

Lex is a scanner generator. .l files contain regular expressions and C code that is executed when they trigger.

Isn't it pure convention which rook is selected? Whenever there are two rooks in the same direction in an FRC startup position the castling rook may be the rook closer to the king or the other one. (If there are more than two it is even more confusing.)

I am not talking about potential castling rights, but actually PERFORMING a castling move on the board (from a string such as "O-O"). Obviously if there are two (or more) rooks in one direction, only the closest one can be involved.

Fabien.

[Tord Romstad]

Isn't it pure convention which rook is selected? Whenever there are two rooks in the same direction in an FRC startup position the castling rook may be the rook closer to the king or the other one. (If there are more than two it is even more confusing.)

I am not talking about potential castling rights, but actually PERFORMING a castling move on the board (from a string such as "O-O"). Obviously if there are two (or more) rooks in one direction, only the closest one can be involved.

Oops, you are right. I never thought about this, but indeed this is a real and serious problem. Considering the enormous number of FRC games I have played, I am surprised that I still haven't seen it happen in practise.

Should be easy to fix, of course. I hope to have a look at it tomorrow.

Tord

[Volker Pittlik]

...Oops, you are right. I never thought about this, but indeed this is a real and serious problem. Considering the enormous number of FRC games I have played, I am surprised that I still haven't seen it happen in practise.
...

I think I found something which happens more often (I use the executable made by Alessandro): If "variant fisherrandom" has been send to Winboard it doesn't send the setup position to the engine.

Example:

Code: Select all

547 <first : feature variants="normal, fischerandom"
547 >first : accepted variants
547 <first : feature fen960=1
547 >first : accepted fen960
547 <first : feature done=1
547 >first : accepted done
563 >first : new
random
563 >first : variant fischerandom
563 >first : level 40 5 0
563 >first : hard
563 >first : ping 1
563 <first : pong 1
26766 >first : time 30000
otim 30000
26766 >first : h1g3
26906 <first : Illegal move: h1g3


This is the start position:
[diag]rbkrbqnn/pppppppp/8/8/8/8/PPPPPPPP/RBKRBQNN w DAda - 0 1[/diag]

rbkrbqnn/pppppppp/8/8/8/8/PPPPPPPP/RBKRBQNN w DAda - 0 1

Because the engine resets the board to the normal initial position after getting "new" from Winboard it assumes the Knights on b1 and g1. "h1g3" must therefore be rejected.

Regards

Volker