search

jhonnold / node-tlcv

Tom's Live Chess Viewer for CCRL Broadcasts on the web!
https://ccrl.live
MIT License
23 stars 8 forks source link

Engines that send Chess960 castling #70

Open ianagbip1oti opened 1 year ago

ianagbip1oti commented 1 year ago

In particular, the engine Cheers sends castling via uci Chess960 style (e1h1/e1a1), https://github.com/Algorhythm-sxv/Cheers/issues/2, It appears that the viewer does not handle this meaning the view of the board gets out of sync with the actual game.

Why this would make sense: chess.js doesn't handle chess960. It parses moves by checking against a list of legal moves, and seeing if the string sent matches one. Since chess960 castling would not be a legal move, it would fail.

Why this wouldn't make sense: TLCV sends moves to the viewer in SAN format. Since TLCV/ChessGUI seems to understand and handle e1h1 as castling just fine, then wouldn't it send it to the viewer as "O-O"?

It may be worth adding a log statement before move parsing so can check what the viewer is actually receiving in these cases. Edit: nvm, there's a log message, Failed to parse, that should log this.

I also don't know if there's something the viewer could do better in the more general case of receiving a move it doesn't understand.

jhonnold commented 1 year ago

What's surprising to me is that the game remains garbled, if a move fails it should just reset to the current FEN coming from the server rather than trying to hold state for the game anymore.

https://github.com/jhonnold/node-tlcv/blob/main/src/handler.ts#L255

This will require a deep investigation.

ianagbip1oti commented 1 year ago

Running this locally, this might not be the viewers problem. I had it attached to a cheers game, and did not see any castling move come through (malformed or otherwise), and the fens coming through seem to be the messed up positions.

(Hope I'm reading the log output correct on that one)