I uploaded a new version of the betza.txt GAME-code include file now, which tests for the presence of morph arrays in the HandelMove routines, and performs the promotion instructions these convey for altering the piece type. This works slightly different than mentioned before, because it has to account for the possibility of an asymmetric game, where the black morphs are not automatically implied by the white ones. So the morphs have to be specified for each color separately.
I tested this now, and it looked like it would work on square boards. (Unfortunately GAME code itself is broken for non-square boards, so it doesn't work there yet.)
For the white specification the ranks are now mentioned from high to low, and there will be no morphing on ranks that are omitted. This to save the user the trouble of writing many trailing zeros for all the ranks where nothing happens, if morphing only takes place near the promotion zone. (Which is usually the case.) So the example I gave before should now be specified in the pre-game code as:
set wmorphers (X Y Z);
set wmorphs assoc
X ((All Q))
Y ((R N B Q Q B N R))
Z ((All Q) (All R) (All B))
;
set bmorphers (x y z);
set bmorphs assoc
x ((All q))
y ((r n b q q b n r))
z ((All q) (All r) (All b))
;
Note the double parentheses: the inner pair encloses the square info on a rank, the outer pair encloses a number of ranks (even if only one rank needs to be specified). A bare 0 between the outer parentheses can still be used to indicate a rank where nothing happens. For a symmetric game the black specification only differs from the white one by having all piece labels in lower case, and the array names strating with b instead of w.
A future version of the Play-Test Applet will append this automatically to the generated Pre-Game code for converting any morph parameters that were specified in the converted Interactive Diagram.
I uploaded a new version of the betza.txt GAME-code include file now, which tests for the presence of morph arrays in the HandelMove routines, and performs the promotion instructions these convey for altering the piece type. This works slightly different than mentioned before, because it has to account for the possibility of an asymmetric game, where the black morphs are not automatically implied by the white ones. So the morphs have to be specified for each color separately.
I tested this now, and it looked like it would work on square boards. (Unfortunately GAME code itself is broken for non-square boards, so it doesn't work there yet.)
For the white specification the ranks are now mentioned from high to low, and there will be no morphing on ranks that are omitted. This to save the user the trouble of writing many trailing zeros for all the ranks where nothing happens, if morphing only takes place near the promotion zone. (Which is usually the case.) So the example I gave before should now be specified in the pre-game code as:
Note the double parentheses: the inner pair encloses the square info on a rank, the outer pair encloses a number of ranks (even if only one rank needs to be specified). A bare 0 between the outer parentheses can still be used to indicate a rank where nothing happens. For a symmetric game the black specification only differs from the white one by having all piece labels in lower case, and the array names strating with b instead of w.
A future version of the Play-Test Applet will append this automatically to the generated Pre-Game code for converting any morph parameters that were specified in the converted Interactive Diagram.