Multiple times the last week the NCM Stockfish Dev have kept given me e2e4 and d2d4 in multiple positions. Both where it is a total blunder and where it is an illegal move
Thank you for reporting this! I just pushed out a fix. It was a bug in NCM. The Stockfish builds were behaving correctly; NCM was sending them bad data.
Here’s the technical explanation of what went wrong:
When you hit Calculate, NCM looks at the board history and finds a starting position and the sequence of legal moves used to arrive at the position for which the move is being calculated – the “analysis position.”
This can get tricky because NCM places very few constraints on how pieces are dragged on the board.
So NCM sends these parameters for each calculation:
- The calculated starting position,
- The calculated sequence of moves to arrive at the analysis position, and
- The analysis position
NCM first sends the starting position and sequence of moves to Stockfish and compares the resulting position to the requested analysis position. 99.9% of the time they are equal. But if the positions differ, NCM sends Stockfish the analysis position.
And that last part is where we messed up. In the case of a discrepancy, NCM was not correctly sending the analysis position, and Stockfish would then calculate from startpos, which is why you were seeing d2d4.
I’m seeing that the en passant square is d6 in the screenshot. I think that’s what tripped up Stockfish. When we send Stockfish a position of “startpos moves d2d4 d7d5”, the resulting position does not have an en passant square, because there is no attacker threatening that square. So, NCM would see the discrepancy, try to set the position explicitly to “rnbqkbnr/ppp1pppp/8/3p4/3P4/8/PPP1PPPP/RNBQKBNR w KQkq - 0 1”, fail because of the bug, and then Stockfish would calculate from startpos, sometimes producing d2d4.
So that raises the question of why NCM was showing the en passant square at d6. One possibility is our paste PGN functionality. We use chess.js (an excellent Javascript library) to parse PGN. When it parses PGN, it always sets the en passant square when a pawn moves two spaces regardless of the presence of an attacker. I’m guessing this is intentional, but NCM should filter out these en passant squares unless an attacker is present.
Anyways, sorry about this, thank you again for reporting it! I’m confident we’ve fixed it, but please let me know if you notice anything like it happening again!