H. G. Muller wrote on Sat, Oct 10, 2020 07:29 AM UTC:
OK, that should simplify highlighting of legal moves. But the rule that (some) captures are mandatory actually is another global rule that creates a difference between legal and pseudo-legal. In Losers Chess this rule has lower priority than the checking rule, here it seems to have higher priority, even when the checking rule would be employed. Pseudo-legal highlighting will be easy here. It will still require me to put a 'hook' into the general code with which a user can interface his own code for the zone confinement; I will make this a function call that passes the full move (fromSqr, toSqr, locustSqr, dropSqr and droppedPiece), which returns whether the move is pseudo-legal, but for efficiency will only be called when a global flag 'zonal' is set.) Besides confinement, such a user-supplied function can also be used for enforcing restrictions what peiec types can capture each other.
It has been useful to attempt this, because it made me discover that the Diagram code had suffered a regression: the Betza compiler used to flag which pieces are inversion-symmetric, so that the GAME-code generator in the wizard page could draw on this to decide whether separate table entries should be made for white and black pieces. This code had disappeared!
I am now thinking how the general GAME-code in the include file could be enhanced in order to interface with variant-specific code. Rule enforcing is in general easy, as when there are extra global rules that outlaw some pseudo-legal moves, you can just test for compliance to these independently of the normal code (e.g. before you call the latter), and 'die' if they are violated. But legal-move highlighting requires such a compliance test to be called from somewhere deep inside the standard code, after the MakeMove of of every pseudo-legal move. Normally the code only does a check test there, and pushes the moves to the legal list when it doesn't expose the King.
The problem with mandatory capture is that you have to know in advance whether such a capture is possible to judge whether a non-capture (or in this case also a non-mandatory capture). An obvious way to do that would be to first make a list of all moves that are legal ignoring the rule, and then test whether there is a mandatory one amongst these. If there is, all non-mandatory moves should be purged from the list. This could be done entirely after the standard code. If I would know how to revoke a previous setlegal command.
@Fergus - What would be the best way to manipulate the $legalmoves array, if I want to remove some moves that in hindsight must not be highlighted after all? Would the following code work?
set tmp $legalmoves;
setsytem legalmoves array; // clear the legal list
for m #tmp:
if fn SomeTest #m:
setlegal m;
endif;
next;
I have another question about GAME-code syntax. In
if fn F X or B:
would this be read as if( B || F(X) ) or as if( F(B || X) )?
OK, that should simplify highlighting of legal moves. But the rule that (some) captures are mandatory actually is another global rule that creates a difference between legal and pseudo-legal. In Losers Chess this rule has lower priority than the checking rule, here it seems to have higher priority, even when the checking rule would be employed. Pseudo-legal highlighting will be easy here. It will still require me to put a 'hook' into the general code with which a user can interface his own code for the zone confinement; I will make this a function call that passes the full move (fromSqr, toSqr, locustSqr, dropSqr and droppedPiece), which returns whether the move is pseudo-legal, but for efficiency will only be called when a global flag 'zonal' is set.) Besides confinement, such a user-supplied function can also be used for enforcing restrictions what peiec types can capture each other.
It has been useful to attempt this, because it made me discover that the Diagram code had suffered a regression: the Betza compiler used to flag which pieces are inversion-symmetric, so that the GAME-code generator in the wizard page could draw on this to decide whether separate table entries should be made for white and black pieces. This code had disappeared!
I am now thinking how the general GAME-code in the include file could be enhanced in order to interface with variant-specific code. Rule enforcing is in general easy, as when there are extra global rules that outlaw some pseudo-legal moves, you can just test for compliance to these independently of the normal code (e.g. before you call the latter), and 'die' if they are violated. But legal-move highlighting requires such a compliance test to be called from somewhere deep inside the standard code, after the MakeMove of of every pseudo-legal move. Normally the code only does a check test there, and pushes the moves to the legal list when it doesn't expose the King.
The problem with mandatory capture is that you have to know in advance whether such a capture is possible to judge whether a non-capture (or in this case also a non-mandatory capture). An obvious way to do that would be to first make a list of all moves that are legal ignoring the rule, and then test whether there is a mandatory one amongst these. If there is, all non-mandatory moves should be purged from the list. This could be done entirely after the standard code. If I would know how to revoke a previous setlegal command.
@Fergus - What would be the best way to manipulate the $legalmoves array, if I want to remove some moves that in hindsight must not be highlighted after all? Would the following code work?
set tmp $legalmoves; setsytem legalmoves array; // clear the legal list for m #tmp: if fn SomeTest #m: setlegal m; endif; next;I have another question about GAME-code syntax. In
would this be read as if( B || F(X) ) or as if( F(B || X) )?