TalkChess.com

Matthias Gemuh wrote:All FRC engines (HAha and KQkq) run fine in ChessGUI.

Have you really tested this in ambiguous situations? It seems to me that what Pedro presents here cannot run correctly in ChessGUI, as his ChessGUI version would NOT understand the AHah notation.

This is not ChessGUIs fault, of course. Unlike Arena, which simply sends an incorrect FEN in ambiguous situations.

hgm wrote: It seems to me that what Pedro presents here cannot run correctly in ChessGUI, as his ChessGUI version would NOT understand the AHah notation.

OK, I forgot a small issue. Shall fix it.
Full AHah for WB engine is of course not according to WB protocol.


Matthias.

As far as I could see, WB protocol does not define the FEN format to be used in variants other than normal, in particular not for FRC or 10x8 variants. There is a proposal for a version 3 protocol which does define it, but this proposal is still secret.

Anyway, there are no known ways to represent all FRC positions without using HAha-type notation at least in some of the cases. The two common standards for doing this are x-FEN (which minimizes the usage of HAha, and uses KQkq where possible) and Shredder-FEN (which uses HAha always). But even in the latter case you would have to understand KQkq for FENs in other variants (unless your engine is 100% dedicated to FRC, and cannot even play normal Chess).

I am inclined to leave the type of FEN that is passed to the engine in the setboard command explicitly undefined in the WinBoard_F specification. That is, currently it sends Shredder-FEN in FRC and normal FEN in other variants, but I reserve the right to change to, say, x-FEN at any time I like, and could even implement it such that WinBoard_F decides upon which FEN to send based on the time of day... The only thing that is defined is what the things it might send you do mean (i.e. A-J indicating the file of the Rook with castling rights, K the outermost rook on the king-side, and Q the outermost Rook on the queen-side).

You're right HGM. Sometimes the English will not let me express myself properly.

I wanted to warn potential programmers engines winboard that if they used winboard_f for FRC should update their engines. The engines will be able to send and receive the castling FRC as O-O, O-O-O, but they will have to be prepared in FRC to receive a shredder-FEN. Moreover such change (FEN --> Shredder-FEN) does not require a big change, just change some 10 lines of code.

In ChessGUI, danasah has to be configured for FRC as WB_OO (castling_OO) as otherwise receive not only the shredder-FEN but the castling indicated as the king capture the rook and danasah does not know this.

Pedro

i'm lost. this thread spun off mine it seems but my question as far as i can tell was never answerd. i dont care about the fens castling rights ( should i ) becuase my engine knows how to assign castling rights in an fr game.

what i wanted to know is how are CASTLE MOVES transmited to the engine. is it still that clunky d1g1 or e1c1 were you have to guess if its a castle move or a real move? is it now always 0-0-0 and 0-0 in ics play? Is it like i think schredder does, king takes rook?

Mike

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.

Mike

adams161 wrote:i'm lost. this thread spun off mine it seems but my question as far as i can tell was never answerd. i dont care about the fens castling rights ( should i ) becuase my engine knows how to assign castling rights in an fr game.

what i wanted to know is how are CASTLE MOVES transmited to the engine. is it still that clunky d1g1 or e1c1 were you have to guess if its a castle move or a real move? is it now always 0-0-0 and 0-0 in ics play? Is it like i think schredder does, king takes rook?

Mike

Hello Michael Adams. Why are you not playing in Dortmund this year ?

For KQkq engines under ChessGUI, castling is 0-0-0 and 0-0.
For HAha engines under ChessGUI, castling is king takes rook.
ChessGUI does not connect to internet yet.

Matthias.

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.)

adams161 wrote: ... 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?

"what if i paste a postion in to analyze it"

agreed this would be important to have the castel rights, I wasnt trying to downplay it or say it didnt matter, I was just trying to get ics play to work with fischer random stably though first ( and my engine currently doesnt support analisis mode). I have got the engine playing fischer random but so far have only played rated with xboard-960.

Mike

Tord already warned me that the FRC additions in WinBoard_x were broken, and that they made a dedicated version of WB for FRC, because to fix the problems seemed to interfere with playing normal Chess. I think everything is fixed in the current WinBoard_F alpha (4.3f.13); I was able to play many normal and wild22 (=FRC) games on ICC between DanaSah960 and Glaurung without any problem. I was also able to adjourn and resume them. I also tested local self-play of DanaSah in FRC, again no problems.

Now that I understand better how the WB-ICS communication protocol works, I might be able to fix the Shatranj problem as well. (It is caused because the board the ICS is parsed before WB knows the game is Shatranj, so that the B and Q the ICS send end up on the board as Bishop and Queen, rather than Elephant and Ferz.) For debugging the Shatranj stuff on ICS, I would need a computer opponent which accepts Shatranj 1+0 unrated matches. Could your engine act as such?