💡📝H. G. Muller wrote on Thu, Nov 3, 2022 09:52 PM UTC:
I have done a complete overhaul of the move-entry routine of the Interactive Diagram.
It is now based on the move generator of the AI,
which has a more elaborate system of move encoding than the old highlighting routines.
In particular there is no longer any limit to the number of locust victims a move can have.
The new system works by generating a list of all moves for the side whose piece gets clicked,
and then click by click delete the moves that do not correspond to the clicks that have been made so far.
In principle all 'destructive' legs of the move have to be indicated in the order the piece traverses those
(according to the XBetza move definition).
So the first click serves to identify the origin,
the next clicks all the locust squares, and finally the destination square.
Hopper mounts or bends in a trajectory do not have to be clicked.
After a click has reduced the number of moves that still conform to the click sequence,
the first not-yet-selected square of all these moves gets highlighted.
If a square gets multiple highlights a click on it won't reduce the number of moves in the list to one,
so it cannot be the final click.
To indicate that, it is highlighted by a blue star (as in the old system).
Even if only a single move would go over that square, but it is not the destination,
it is highlighted this way, and the user is expected to click subsequent squares visited by the move until the destination.
(There is in general no 'autocomplete of moves'.)
Square that would finish the move entry when clicked,
because it is only used as destination of a single move,
are highlighted depending on the type of move (capture, non-capture, initial, castling...),
as in the old system.
The system tries to be smart w.r.t. the click order, though.
It recognizes moves that were generated as e.p. captures or castlings,
and does not require you to click the e.p. victim or Rook as locust squares.
For each move that is generated it assigns an order in which the relevant squares have to be clicked to select that move.
For castlings it actually does define the third click (after King origin and destination) to identify the Rook,
(which is essential to disambiguate a normal King move from a castling where the King steps only a single square).
But castlings are an exception to the rule that moves are not auto-completed,
so if there is no ambiguity it would not request the Rook click.
For locust captures it uses a heuristic to distinguish 'shooters' from 'tramplers'.
If the XBetza definition of the move ends in a back-and-forth locust capture,
that either does not consist of King steps, or the point from where it started was not reached by a King step,
it is classified as a shooter.
The click order is then modified so that the destination has to be clicked before the locust victim,
and no click is needed to return to the destination.
Tramplers keep using the standard click order, where they visite all locust squares before the destination gets clicked.
There is an additional issue:
The AI's move format not only specifies squares that get mutated,
but can also specify one or more squares where e.p. rights get created.
Sometimes two moves to the same destination only differ in the e.p. rights they create
(for a multi-path piece that can be e.p. captured).
Betza's Doublemove Chess is an example of that.
Such ambiguity is also recognized by the new move-entry system,
and the e.p. square is in that case included in the click order (just before the destination).
Normally e.p. squares would not have to be clicked.
The system seems to work now; I still have to integrate it with the AI and game-recording routines.
It will not be used as the default move entry for the Diagram script until that is also done.
But here already is a Diagram with a variety of pieces that show some of the possibilities:
The Forest Ox is a shooter, which optionally destroys an adjacent piece after his Knight move.
The Valkyrie is a swapper, that can relocate a friently piece at its destination anywhere along its path.
Both these pieces are from Odin's Rune Chess.
The Dragon is the Lion Dog from the large Shogi variants;
it can capture up to 3 pieces.
The Lion is from Chu Shogi.
Both these pieces are tramplers.
The Double Knight can make two Knight moves in one turn, but only if both are non-captures.
After a double move it can be e.p. captured (by Pawns, the only pieces that can do e.p. capture here).
It also can do a single Knight move.
The King has flexible castling, 0 to 4 steps.
I have done a complete overhaul of the move-entry routine of the Interactive Diagram. It is now based on the move generator of the AI, which has a more elaborate system of move encoding than the old highlighting routines. In particular there is no longer any limit to the number of locust victims a move can have.
The new system works by generating a list of all moves for the side whose piece gets clicked, and then click by click delete the moves that do not correspond to the clicks that have been made so far. In principle all 'destructive' legs of the move have to be indicated in the order the piece traverses those (according to the XBetza move definition). So the first click serves to identify the origin, the next clicks all the locust squares, and finally the destination square. Hopper mounts or bends in a trajectory do not have to be clicked.
After a click has reduced the number of moves that still conform to the click sequence, the first not-yet-selected square of all these moves gets highlighted. If a square gets multiple highlights a click on it won't reduce the number of moves in the list to one, so it cannot be the final click. To indicate that, it is highlighted by a blue star (as in the old system). Even if only a single move would go over that square, but it is not the destination, it is highlighted this way, and the user is expected to click subsequent squares visited by the move until the destination. (There is in general no 'autocomplete of moves'.) Square that would finish the move entry when clicked, because it is only used as destination of a single move, are highlighted depending on the type of move (capture, non-capture, initial, castling...), as in the old system.
The system tries to be smart w.r.t. the click order, though. It recognizes moves that were generated as e.p. captures or castlings, and does not require you to click the e.p. victim or Rook as locust squares. For each move that is generated it assigns an order in which the relevant squares have to be clicked to select that move. For castlings it actually does define the third click (after King origin and destination) to identify the Rook, (which is essential to disambiguate a normal King move from a castling where the King steps only a single square). But castlings are an exception to the rule that moves are not auto-completed, so if there is no ambiguity it would not request the Rook click.
For locust captures it uses a heuristic to distinguish 'shooters' from 'tramplers'. If the XBetza definition of the move ends in a back-and-forth locust capture, that either does not consist of King steps, or the point from where it started was not reached by a King step, it is classified as a shooter. The click order is then modified so that the destination has to be clicked before the locust victim, and no click is needed to return to the destination. Tramplers keep using the standard click order, where they visite all locust squares before the destination gets clicked.
There is an additional issue: The AI's move format not only specifies squares that get mutated, but can also specify one or more squares where e.p. rights get created. Sometimes two moves to the same destination only differ in the e.p. rights they create (for a multi-path piece that can be e.p. captured). Betza's Doublemove Chess is an example of that. Such ambiguity is also recognized by the new move-entry system, and the e.p. square is in that case included in the click order (just before the destination). Normally e.p. squares would not have to be clicked.
The system seems to work now; I still have to integrate it with the AI and game-recording routines. It will not be used as the default move entry for the Diagram script until that is also done. But here already is a Diagram with a variety of pieces that show some of the possibilities:
Move-Entry test
The Forest Ox is a shooter, which optionally destroys an adjacent piece after his Knight move. The Valkyrie is a swapper, that can relocate a friently piece at its destination anywhere along its path. Both these pieces are from Odin's Rune Chess. The Dragon is the Lion Dog from the large Shogi variants; it can capture up to 3 pieces. The Lion is from Chu Shogi. Both these pieces are tramplers. The Double Knight can make two Knight moves in one turn, but only if both are non-captures. After a double move it can be e.p. captured (by Pawns, the only pieces that can do e.p. capture here). It also can do a single Knight move. The King has flexible castling, 0 to 4 steps.