niklasf/shakmaty

UCI castling not recognized by some GUIs

zxqfl opened this issue · 5 comments

zxqfl commented

shakmaty writes a black kingside castle as e8h8, but PyChess only understands e8g8. It looks like shakmaty uses e8h8 on purpose to accomodate Chess960 games, so I wasn't sure of the best way to fix this issue.

This is the fix I'm using in my own code:

fn map_uci(x: String) -> String {
    match x.as_str() {
        "e8h8" => "e8g8".into(),
        "e8a8" => "e8c8".into(),
        "e1h1" => "e1g1".into(),
        "e1a1" => "e1c1".into(),
        _ => x,
    }
}

@zxqfl may I ask you what 'PyChess only understands e8g8' means exactly? If this is a real problem, can you file an issue about that in PyChess github project please?
@niklasf sorry for the offtopic :)

zxqfl commented

@gbtami I mean that when an engine outputs e8h8 PyChess terminates the game because it doesn't think it's a legal move.

I expect that this issue is not specific to PyChess since http://wbec-ridderkerk.nl/html/UCIProtocol.html only lists e1g1 as an example of valid castling notation.

Indeed, Stockfish writes e8g8, not e8h8, when it isn't playing a Chess960 game: https://github.com/official-stockfish/Stockfish/blob/master/src/uci.cpp

I agree.

For Chess960 e8h8 (king-takes-rook) notation is sometimes necessary to differentiate between a king move and a castling move.

Does shakmaty currently support Chess960 play?

@zxqfl thx for clarifying!

Yes, shakmaty supports Chess960. Unfortunately it looks like we can't get away with supporting only Chess960. I pushed a (non-backwards compatible) suggestion for a fix.