💡📝H. G. Muller wrote on Thu, Feb 2, 2023 10:34 PM UTC:
I think I will implement the following interface for extending the Interactive Diagram with user-supplied scripts:
The user can supply a JavaScript function xxxTinker(m), where xxx is the satellite name for the Diagram (default value: 'piece'), and m is an array describing the move. This array will contain the board coordinates (which always start counting at 0) for the squares involved in the move, the rank number following the file number of each square. The first square (in m[0] and m[1]) will be the origin, the second (m[2] and m[3]) the destination, and after that will come the locust squares in the reverse order as the XBetza description visited them. The element m[-2] will specify how many squares will be altered by the move. (So if there are no locust squares this will be 2: the origin and destination.) After the locust squares can come squares where e.p. rights are generated; these are not counted in m[-2]. It is not specified how many there are of those, and most moves do not have them.
The element m[-1] contains the promotion piece for the move (i.e. the piece that will appear on the destination square), but it might or might not be initialized.
This xxxTinker() funtion can then modify the m array in any way it wants. Likely modifications are altering or supplying a promotion piece in m[-1], or adding locust squares by writing those in the appropriate m[] elements, and increasing m[-2] correspondingly. When it is done tailoring the move, it should return a value to indicate to the standard script what it should do with that move. Possible return valueas ar:
-2 Terminates game immediately, as a win for the player that can do the move (as if the move captured a King).
-1 Terminates the game as a win if the player making it survives the reply of his opponent (as with Shatranj baring).
0 Take the move as we now prepared it (which could be unaltered).
1 Discard the move; it is forbidden (e.g. due to zonal confinement, or improper promotion piece).
2 Suppress deferral of normal Shogi promotion (as per maxPromote and promoOffset).
3 Take the promotion we specified in m[-1], but also add a move that defers.
4 Perform a Chess-like promotion. Moves with every possible promotion type will be subjected to xxxTinker(), and can be
rejected or accepted by it in the normal way (returning 1 or 0).
The value 4 should only be returned when the value of m[-1] was undefined (if(!m[-1])...), to make a move that otherwise would not promote at all offer a Chess-like promotion choice. If m[-1] does have a value > 0 the promotion choice has already been made, and we must only reject or accept it.
I think I will implement the following interface for extending the Interactive Diagram with user-supplied scripts:
The user can supply a JavaScript function xxxTinker(m), where xxx is the satellite name for the Diagram (default value: 'piece'), and m is an array describing the move. This array will contain the board coordinates (which always start counting at 0) for the squares involved in the move, the rank number following the file number of each square. The first square (in m[0] and m[1]) will be the origin, the second (m[2] and m[3]) the destination, and after that will come the locust squares in the reverse order as the XBetza description visited them. The element m[-2] will specify how many squares will be altered by the move. (So if there are no locust squares this will be 2: the origin and destination.) After the locust squares can come squares where e.p. rights are generated; these are not counted in m[-2]. It is not specified how many there are of those, and most moves do not have them.
The element m[-1] contains the promotion piece for the move (i.e. the piece that will appear on the destination square), but it might or might not be initialized.
This xxxTinker() funtion can then modify the m array in any way it wants. Likely modifications are altering or supplying a promotion piece in m[-1], or adding locust squares by writing those in the appropriate m[] elements, and increasing m[-2] correspondingly. When it is done tailoring the move, it should return a value to indicate to the standard script what it should do with that move. Possible return valueas ar:
The value 4 should only be returned when the value of m[-1] was undefined (if(!m[-1])...), to make a move that otherwise would not promote at all offer a Chess-like promotion choice. If m[-1] does have a value > 0 the promotion choice has already been made, and we must only reject or accept it.