💡📝H. G. Muller wrote on Fri, Nov 3, 2017 09:54 AM UTC:
It seems I had broken something in the diagram script. Or rather, the changes for the new highlighting method activated a latent bug in the move generation. The diagram stores both pieces and highlight indicators in a board cell. But when testing whether the first leg of a hook mover has bumped into something, it was not ignoring the highlight indications. And because the Hook mover is RmasR, the squares over which the first leg of the hook move goes would already have been highlighted by the plain R component. Before I did not mark squares for normal moves or captures (just those that were targets lof locust captures, e.p. capture or castling), but I started doing that for resolving collisions between such moves and normal moves, to avoid they would eclipse each other in the move diagrams, and to make enforcement of legality possible. The problem would have manifested itself before if a hook move tried to go over an e.p. or locust-capture square, but of course no one ever conceived a piece that combined such moves.
I now fixed this by ignoring the highlight markers when testing whether the first leg is obstructed or can continue. (Flush browser cache!) Thanks for finding and reporting this.
@Aurelian: Not sure what you mean about the Lance. Is that in the piece lists next to the diagram, or in the piece table? I only see one Lance in either case.
It seems I had broken something in the diagram script. Or rather, the changes for the new highlighting method activated a latent bug in the move generation. The diagram stores both pieces and highlight indicators in a board cell. But when testing whether the first leg of a hook mover has bumped into something, it was not ignoring the highlight indications. And because the Hook mover is RmasR, the squares over which the first leg of the hook move goes would already have been highlighted by the plain R component. Before I did not mark squares for normal moves or captures (just those that were targets lof locust captures, e.p. capture or castling), but I started doing that for resolving collisions between such moves and normal moves, to avoid they would eclipse each other in the move diagrams, and to make enforcement of legality possible. The problem would have manifested itself before if a hook move tried to go over an e.p. or locust-capture square, but of course no one ever conceived a piece that combined such moves.
I now fixed this by ignoring the highlight markers when testing whether the first leg is obstructed or can continue. (Flush browser cache!) Thanks for finding and reporting this.
@Aurelian: Not sure what you mean about the Lance. Is that in the piece lists next to the diagram, or in the piece table? I only see one Lance in either case.