lichess.org
Donate

Atomic replay bug

probably because which knight is not specified, and taking with the other one would be an illegal move, weird bug
I think the issue is this on line 485 in generate_moves() of github.com/ornicar/chess.js/blob/master/chess.js

/* do we want legal moves? */
var legal = (typeof options !== 'undefined' && 'legal' in options) ?
options.legal : (game_type !== GAME_ATOMIC);

So it generates all moves, and so the replayer part of the code needs disambiguated SAN, while the other part of the code must not (for it produces the PGN without it).

While en passant bugs appear multiple times on the forum and the issues at github, I don't know if this one has been caught before.

You can paste 1. e4 e6 2. Nc3 Bb4 3. d4 d5 4. Ne2 and it will work in Standard, but not in Atomic, you need Nge2.

The solution is probably to filter out moves which allow the king to be captured, unless the move exploded the opponent's king (see lines 690-708 of that file).
Staring at this code for make_move() in that file, I'm not sure it correctly handles removing castling privileges when you explode your own unmoved rook (it has code for when you explode the opponent's rook, or you move your rook, but I don't see how it handles the case where as White you would play Nxg1 and blow up your own Rh1).
If you want my attempt to fix the disambiguated SAN problem in Atomic replays.

Remove GAME_ATOMIC from line 487.

At line 700-704, instead have

make_move(moves[i]);
if (game_type == GAME_ATOMIC && // explode opp king
board[kings[us]] && !board[kings[them]) // but not ours
legal_moves.push(moves[i]);
else if (game_type == GAME_ANTICHESS ||
(board[kings[us]] && !king_attacked(us)))
legal_moves.push(moves[i]);
undo_move();
I also verified that the self-exploding of castling rights is indeed erroneously omitted (in the replayer).

[White "me"]
[Black "you"]
[Variant "atomic"]
[Result "*"]

1. Nf3 Nf6 2. d4 Nh5 3. d5 Nf4 4. d6 Nh3 5. dxc7 Ng1 6. Nxg1 *

The final FEN is given in the replayer is given as
r3kb1r/pp1ppppp/8/8/8/8/PPP1PPPP/RNBQK3 b KQkq - 0 6
while White should not have kingside castling privileges.
Good catch. Now that White doesn't have a kingside rook O-O should be illegal. I wonder if that means that right now lichess would allow you to castle kingside with a promoted rook moved to h1?
An early attempt I had with ATOMIC-GUI contained a problem with this, at least it was sending incorrect castling privs to Atomkraft, and the latter would crash after analyzing for sufficiently long.

I referenced both bugs in this thread in github.com/ornicar/lila/issues
I had tried to do this before, but chess.js does not allow issues on its github.
It seems that the answer is "no" to the promoted rook, though I am not sure why not.

[White "me"]
[Black "you"]
[Result "*"]
[Variant "atomic"]

1. Nf3 Nf6 2. d4 Nh5 3. d5 Nf4 4. d6 Nh3 5. dxc7 Ng1 6. Nxg1 f5 7. c4 f4 8. c5 f3 9. c6 fxg2 10. c7 Rd8 11. c8=R g6 12. Rc3 Ra8 13. Rg3 Bh6 14. Rg1 Bxc1 15. Rh1 h6 16. O-O *

Removing the O-O at the end gives a valid PGN. The listed FEN then has "KQk" (a sufficient but dodgy way to "fix" the problem would see the move Rh1 unset White kingside privs), but still O-O is unallowed. Probably some other part of the code validates the PGN in general (rejecting it here), and then passes it on to the replayer which follows its own path?

This topic has been archived and can no longer be replied to.