Funny killer move bug

[Henk]

My killer move handler validated a castling move for a rook as valid, for the rook was on e1 and the move was e1-g1. Software crashed of course when doing the castling move.

[Henk]

Maybe not that funny if a killer move was meant for a bishop but the square is occupied by the queen, software won't notice. I think I have to store pieceType with the killer move to disambiguate.

[Angrim]

Maybe not that funny if a killer move was meant for a bishop but the square is occupied by the queen, software won't notice. I think I have to store pieceType with the killer move to disambiguate.

All that "error" would do is faintly mess up your move ordering. It might even be that the move is still a good one with the queen there. So it shouldn't be a significant problem.

[Henk]

I think it is because I don't use the pointer (reference) of the move for comparison.

But that is not possible if I would use bitboards to test if a move is valid for a piece or not.

[lauriet]

Why are you telling us ?
If its a bug..........fix it

[Henk]

I think adding a piece or piece type to a move costs too much memory. So it's probably best to do nothing against it. Priority too low. I already fixed it for engine doesn't crash anymore, but it is a weak point if I change the implementation of killer moves sometime software will crash again if I would forget this bug that moves are ambiguous if you don't know which move belongs to which piece.

[
It took me quite a long time to understand what was going on here. I even restored a backup (losing changes of a week) for this before I tried again to fix it. Move ordering gets easily too complicated.
]

[Tom Likens]

Why are you telling us ?
If its a bug..........fix it

I don't mind hearing about people's bug reports. Often they're amusing and we've all been there. This is a programming forum after all.

regards,
--tom