WinBoard and FRC
Posted: 25 Jun 2008, 18:15
I just fixed an alpha version of WinBoard_F that should be fully FRC compatible. The previous versions has some problems when playing on ICS, in particular when resuming an adjourned game. I had never tested them for ICS play, so they only worked for engine-engine games.
The current version ( http://home.hccnet.nl/h.g.muller/alpha.tst , rename to winboard.exe) is extensively tested on ICC, and seems to correctly handle castling rights when playing, and when restoring an adjourned game.
This was not trivial, as WinBoard turns out to use completely different mechanisms for local playing and for ICS play: in local playing each new position is derived from the previous position, and the move the engine or user sends it. In ICS play, the previous position is completely ignored, and the position as it will be after the move is loaded from the ICS. The position description sent by ICS does also contain the castling rights (not as FEN, alas), but in FRC the transmitted castling rights are in general wrong! (Only corner Rooks get castling rights, and if two Rooks are on the same side of the King, the format does not allow spcifying which Rook has the rights...) But when resuming an adjourned game, the positions are again derived from previous positions by moves, but in a slightly different way from when engines play (using ApplyMove() rather than MakeMove()). So it was a very messy operation.
I would be very grateful if people could try out the alpha.tst in normal Chess and FRC, on local engine-engine and ICS play (playing, resuming, observing other games) to see if everything works, and if I haven't broken anything.
The current version ( http://home.hccnet.nl/h.g.muller/alpha.tst , rename to winboard.exe) is extensively tested on ICC, and seems to correctly handle castling rights when playing, and when restoring an adjourned game.
This was not trivial, as WinBoard turns out to use completely different mechanisms for local playing and for ICS play: in local playing each new position is derived from the previous position, and the move the engine or user sends it. In ICS play, the previous position is completely ignored, and the position as it will be after the move is loaded from the ICS. The position description sent by ICS does also contain the castling rights (not as FEN, alas), but in FRC the transmitted castling rights are in general wrong! (Only corner Rooks get castling rights, and if two Rooks are on the same side of the King, the format does not allow spcifying which Rook has the rights...) But when resuming an adjourned game, the positions are again derived from previous positions by moves, but in a slightly different way from when engines play (using ApplyMove() rather than MakeMove()). So it was a very messy operation.
I would be very grateful if people could try out the alpha.tst in normal Chess and FRC, on local engine-engine and ICS play (playing, resuming, observing other games) to see if everything works, and if I haven't broken anything.