Closed DSARichard closed 1 year ago
Thanks for the report. I can imagine where this might be coming from since pawn moves are generated completely separately from other pieces. It definitely is not intended, and since fairyground uses the same game logic under the hood it should be an issue in all Fairy-SF based code.
Could you please add a sample configuration where this occurs to reproduce the problem?
Edit: Bug should be about missing restriction of capture and non-capture targets to board_bb(c, PAWN)
at
https://github.com/ianfab/Fairy-Stockfish/blob/8ec72eff3bcf82648396756d03085d2c9363257d/src/movegen.cpp#L117-L119
I will just paste a short simplified version that retains the bug:
Edit: Or this which is much more succinct and easy to test: [chessvariant:chess] mobilityRegionWhitePawn = f2 mobilityRegionBlackPawn = d7 startFen = 8/3p4/8/8/8/8/5P2/8 w - - 0 1
When update korea janggi??
I believe there may be a problem with the mobilityRegion of pawns: they are able to move out of their mobilityRegion.
Recently I tried to playing with some custom variants in browser fairyground (https://fairyground.vercel.app/). I attempted to create an inaccessible hole in the center of the board. Since the asterisk FEN notation in WinBoard is of course not available in fairyground, I tried tediously defining the mobilityRegion for each of the pieces, and then filled the hole with immobile pieces to block long-range pieces. All pieces functioned correctly except pawns, which were able to capture the immobile pieces of opposite color in the inaccessible region somehow.
Is this expected or unexpected behavior? If not, is this solely a problem with fairyground, or does it manifest in others too? Apologies if there is a simple mistake I have committed or if I have missed a solution easily available.