🕸📝Fergus Duniho wrote on Wed, Jan 11, 2023 06:27 PM UTC:
Because GAME Code was storing legal moves in two separate variables, and I wasn't always keeping this in mind, the stalemated subroutine in the fairychess include file was returning the wrong result for positions like this one:
It was claiming this was checkmate when the check could be prevented by capturing the Queen with a Pawn or blocking with one on g1. This was because the Pawn moves, which included a promotion, were being stored in $extralegal instead of in $legalmoves, which stored legal moves only as coordinate pairs, and the stalemated subroutine, as well as other similar subroutines, checked only the value of $legalmoves. To keep things simpler, I abolished the $extralegal variable, and I stored all legal moves in $legalmoves as strings using notation, and not as arrays of coordinates. With this change made, I was able to slim down the findmates subroutine to this:
// Finds each mating move in current position.
// Parameters:
// side: which side is moving
sub findmates side:
local enemyking king mates moves mv;
if match #side 1 white White first:
set king #Kpos;
set enemyking #kpos;
else:
set king #kpos;
set enemyking #Kpos;
endif;
set mates ();
ban none;
setsystem maxmove 0;
store main;
setsystem legalmoves ();
if not sub stalemated #king:
set lglmvs $legalmoves;
foreach move #lglmvs:
set moves explode chr 59 #move;
foreach mv #moves:
set mv trim #mv;
eval "MOVE: {#mv}";
next;
if sub checked #enemyking:
setsystem legalmoves ();
if sub stalemated #enemyking:
push mates #move;
endif;
endif;
restore main;
next;
endif;
setsystem legalmoves #mates;
endsub;
I did notice and correct one problem after this. It was recording some moves as belonging to the @ piece, which is the piece symbol used for empty spaces. This was because it was running the function for converting to notation as soon as setlegal was called, which happened to come before restoring the position. To correct for this, I had it get the piece type from the destination space if the origin space was empty, and if both were empty to not include the piece type. In the future, it would help to call setlegal only after restoring the position or to explicitly spell out the move if it will be anything out of the ordinary.
Because GAME Code was storing legal moves in two separate variables, and I wasn't always keeping this in mind, the
stalemated
subroutine in the fairychess include file was returning the wrong result for positions like this one:It was claiming this was checkmate when the check could be prevented by capturing the Queen with a Pawn or blocking with one on g1. This was because the Pawn moves, which included a promotion, were being stored in
$extralegal
instead of in$legalmoves
, which stored legal moves only as coordinate pairs, and thestalemated
subroutine, as well as other similar subroutines, checked only the value of$legalmoves
. To keep things simpler, I abolished the$extralegal
variable, and I stored all legal moves in$legalmoves
as strings using notation, and not as arrays of coordinates. With this change made, I was able to slim down thefindmates
subroutine to this:I did notice and correct one problem after this. It was recording some moves as belonging to the @ piece, which is the piece symbol used for empty spaces. This was because it was running the function for converting to notation as soon as
setlegal
was called, which happened to come before restoring the position. To correct for this, I had it get the piece type from the destination space if the origin space was empty, and if both were empty to not include the piece type. In the future, it would help to callsetlegal
only after restoring the position or to explicitly spell out the move if it will be anything out of the ordinary.