Each line in the legdefs array represents the leg of a move, and contains either 5 or 4 numbers. The first leg always contains 5 numbers, the first number indicating how many legs the move has. A zero there indicates no more moves follow for that piece.
The other 4 numbers are range (1 = leaper), x-step y-step and 'mode'. The latter describes what must occupy the target square for the leg to be possible.
Ranges smaller than 1 are of course meaningless, and those are used to indicate special cases that cannot be described as a (repeated) step. Such as imitation. These 'invalid' rages are recognized, and will cause execution of dedicated GAME code to handle the particular case. E.g. -1 would be used for the variable range of Pawns moving up to the board half. A -3 would cause calling of a user-supplied GAME code subroutine for generating the move.
I guess there is currently a mismatch between how the Interactive Diagram handles imitation (indicating it by some bit in the 'mode') and how the betza.txt GAME-code include file handles it (through range = -2). It would have been the task of the Play-Test Applet to make that translation when you make it generate GAME code. I cannot recall changing any of these. But I must have, if you say it worked before. In any case I should fix the Play-Test Applet to emit the -2 as range when the mode specifies imitation.
Each line in the legdefs array represents the leg of a move, and contains either 5 or 4 numbers. The first leg always contains 5 numbers, the first number indicating how many legs the move has. A zero there indicates no more moves follow for that piece.
The other 4 numbers are range (1 = leaper), x-step y-step and 'mode'. The latter describes what must occupy the target square for the leg to be possible.
Ranges smaller than 1 are of course meaningless, and those are used to indicate special cases that cannot be described as a (repeated) step. Such as imitation. These 'invalid' rages are recognized, and will cause execution of dedicated GAME code to handle the particular case. E.g. -1 would be used for the variable range of Pawns moving up to the board half. A -3 would cause calling of a user-supplied GAME code subroutine for generating the move.
I guess there is currently a mismatch between how the Interactive Diagram handles imitation (indicating it by some bit in the 'mode') and how the betza.txt GAME-code include file handles it (through range = -2). It would have been the task of the Play-Test Applet to make that translation when you make it generate GAME code. I cannot recall changing any of these. But I must have, if you say it worked before. In any case I should fix the Play-Test Applet to emit the -2 as range when the mode specifies imitation.