💡📝H. G. Muller wrote on Tue, Jan 31, 2023 10:01 AM UTC:
I am getting less and less happy with the WeirdPromotion() and BadZone() extension system for the Interactive Diagram. It is inconvenient that these are two different functions, and a shortcoming of WeirdPromotion() is its limited power for adding side effects to the move, and that it gets passed only a single locust square (while the NewClick entry system allows arbitrary many locust victims). This has been somewhat ameliorated by the kamikaze and burn/atomic pseudo-promotion codes, but there still remain lots of things that cannot be done.
It would be much better to have a single user-supplied function AlterMove(move), which gets the internal move representation passed as the single argument. This move representation is an array, which contains the coordinates of all involved squares (origin, destination, all locust squares, all squares where e.p. rights are generated, the promotion piece...). And what is even better: AlterMove() could make changes in that, (like adding locust squares), which would affect the original. As, unlike scalar objects, when an array gets passed to a function it will be the real thing, not a copy. So it could directly alter the promotion choice in the move, rather than returning it as a result, and leaving it for the standard code to incorporate it in the move.
The return value then could be reserved for signalling only. Like indicating that the move or promotion choice is forbidden, so that the move should be deleted from the move list. Or that the move is winning (e.g. by reaching a goal square). Or that a move thought to be a non-promotion should unexpectedly offer promotion choice (making the standard script duplicate the move, this time with other promotion choices, subjecting these again to AlterMove() to test whether these are allowed, and add those to the move list when they are).
This would for instance also allow implementation of pieces like the Ultima Coordinator, which might need locust captures on distant squares at the intersection of its coordinate lines and those of the King. By switching the Diagram's tracking function on, the location of the King would be easily available, and the AlterMove() routine would just have to combine these with the coordinates of the destination on a Coordinator move, test whether there is an enemy there, and if there is, add it as a locust square to the move.
For backward compatibility the standard script could contain a default function for AlterMove(), which it invokes if the user has supplied a WeirdPromotion() or BadZone(), to call the latter two for the move in question, and translate the return values to the actions these request. (Like altering the promotion piece, or return the 'forbidden' code.) This seems a simpler and more powerful system. Perhaps some standard routines could be offered to simplify writing AlterMove(), like AddLocustSquare(move, x, y).
I am also wondering if I should devote some attention to configurable use of the trackPieces functionality in such a standard version of AlterMove(). Passive effects on adjacent pieces are not that uncommon in variants, especially immobilization. So where trackPieces=N now just serves to switch on the tracking for non-zero N, I could have N indicate a piece type for which the adjacent squares should automatically be marked in a neighbors[] array indexed by square number. And supply a new Diagram parameter neighbors, which could be given the values immobilize, pacify or burn, which then would activate to either forbid all moves with a piece standing on a marked square, forbid all its captures, or make moves to a marked square kamikaze moves, respectively. Then these rules could be implemented purely by configuration, without writing any script.
I am getting less and less happy with the WeirdPromotion() and BadZone() extension system for the Interactive Diagram. It is inconvenient that these are two different functions, and a shortcoming of WeirdPromotion() is its limited power for adding side effects to the move, and that it gets passed only a single locust square (while the NewClick entry system allows arbitrary many locust victims). This has been somewhat ameliorated by the kamikaze and burn/atomic pseudo-promotion codes, but there still remain lots of things that cannot be done.
It would be much better to have a single user-supplied function AlterMove(move), which gets the internal move representation passed as the single argument. This move representation is an array, which contains the coordinates of all involved squares (origin, destination, all locust squares, all squares where e.p. rights are generated, the promotion piece...). And what is even better: AlterMove() could make changes in that, (like adding locust squares), which would affect the original. As, unlike scalar objects, when an array gets passed to a function it will be the real thing, not a copy. So it could directly alter the promotion choice in the move, rather than returning it as a result, and leaving it for the standard code to incorporate it in the move.
The return value then could be reserved for signalling only. Like indicating that the move or promotion choice is forbidden, so that the move should be deleted from the move list. Or that the move is winning (e.g. by reaching a goal square). Or that a move thought to be a non-promotion should unexpectedly offer promotion choice (making the standard script duplicate the move, this time with other promotion choices, subjecting these again to AlterMove() to test whether these are allowed, and add those to the move list when they are).
This would for instance also allow implementation of pieces like the Ultima Coordinator, which might need locust captures on distant squares at the intersection of its coordinate lines and those of the King. By switching the Diagram's tracking function on, the location of the King would be easily available, and the AlterMove() routine would just have to combine these with the coordinates of the destination on a Coordinator move, test whether there is an enemy there, and if there is, add it as a locust square to the move.
For backward compatibility the standard script could contain a default function for AlterMove(), which it invokes if the user has supplied a WeirdPromotion() or BadZone(), to call the latter two for the move in question, and translate the return values to the actions these request. (Like altering the promotion piece, or return the 'forbidden' code.) This seems a simpler and more powerful system. Perhaps some standard routines could be offered to simplify writing AlterMove(), like AddLocustSquare(move, x, y).
I am also wondering if I should devote some attention to configurable use of the trackPieces functionality in such a standard version of AlterMove(). Passive effects on adjacent pieces are not that uncommon in variants, especially immobilization. So where trackPieces=N now just serves to switch on the tracking for non-zero N, I could have N indicate a piece type for which the adjacent squares should automatically be marked in a neighbors[] array indexed by square number. And supply a new Diagram parameter neighbors, which could be given the values immobilize, pacify or burn, which then would activate to either forbid all moves with a piece standing on a marked square, forbid all its captures, or make moves to a marked square kamikaze moves, respectively. Then these rules could be implemented purely by configuration, without writing any script.