Comments/Ratings for a Single Item
H. G. Muller wrote on Sat, Oct 10, 2020 03:49 PM UTC:Zone confinement now also works for the highlighting, with the aid of the 'user-supplied' BadZone function. And I have implemented non-final-leg e.p. capture in the betza.txt include file now, so that works too.
Only remaining imperfection is that when an edge capture is mandatory it still highlights other moves.
@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;
You made a typo. setsytem should be setsystem. With that fixed, it looks like it would work. Since the documentation did not mention that it would work, I updated the documentation. But it will work only for legal moves described as arrays of coordinates for $legalmoves. It will not work for legal moves entered as strings.
Greg Strong wrote on Fri, Dec 11, 2020 08:36 PM UTC:I forgot about the preset H.G. made:
Is this ready for me to post? It looks like everything is correct except for highlighting moves that wouldn't be allowed when a mandatory edge capture is available. (It still doesn't let you actually make the illegal move, so that's good enough.)
H. G. Muller wrote on Sat, Dec 12, 2020 03:49 PM UTC in reply to Greg Strong from Fri Dec 11 08:36 PM:Ah yes, I did not pay any attention to that since Fergus responded to my question. Everything should work, except that the highlingting doesn't suppress moves of pieces when there is an edge-capture to make. My idea for that was to add some Post-Game code to post-edit the list of legal moves by throwing away all moves that are not edge captures. If the list is empty, thenthe original list was OK, if it is not, the cleansed list becomes the new list.
There still is one other thing I don't like in the code, though. The include code now calls a routine BadZone to vet the pseudo-legal moves it generates, when 'zonal' is set to 1. This routine gets all squares of the move passed (origin, destination, locust square, drop square, and even dropped type). Currently it is blind to any 'hop squares', though. While there also exist variants (Janggi!) where a hopper cannot hop over some piece types. The hop square is not part of the move description, though. For that reason the code can handle moves with arbitrarily many hops (while the number of locust victims is limited to 1).
If I ever change the inteface between BadZone and the rest of the code, it would break all presets that relied on this interface. (Because the BadZone definitions are in the presets, and the change would be in the included file.) So perhaps I should better fix this first.
5 comments displayed
Permalink to the exact comments currently displayed.
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) )?