adams161 wrote:ok i see i missed that frank said castle is transmitted as 0-0 and 0-0-0. I could never figure out how to get it to work in ics play. It was always sent as e1c1 etc.
In home play me against the machine it did transmit as 0-0. There is a program argument to ask for 0-0 but it deafults to true so its not needed. I think I tried turnin git on anyway and it had no effect. i always got castle as e1c1 or d1f1 ( 8 possibliites) which is confusing becuase you must figure out if its a castle move or a real move.
I suppose that you are talking here about the previous WinBoard_F version. It might have done this because it did not recognize the string the ICS sent it as a castling, as in WinBoard FRC castlings are recognized from their move type as determined by the move parser. And move type IllegalMove has precedence over all other moves. And the castlings in FRC were flagged as illegal, because there were no castling rights, not even in the initial position. This because the ICS does not send castling rights correctly in FRC. (Rooks that are not in a corner do not get rights.) As I never tried it on ICS, I was not aware of that.
I fixed all that in the current version, by ignoring the castling rights sent by the ICS, but reconstructing castling rights from the board, or copying them from the initial position. That this might grant castling rights to Rooks that have already moved is no problem, as in ICS play it is the ICS that catches illegal moves, not WinBoard.
So all castlings should now be recognized as such, and are thus sent as O-O or O-O-O in FRC. Both in ICS and local play. (I have not tested Human-engine play now, because that was already working in the previous version.)
... becuase my engine knows how to assign castling rights in an fr game.
But what if you paste a FEN of an FRC game in progress, to analyse it?