H.G., when you have a minute or two, could you take a look at this game's ID? I fixed the Wizard, and I think I got the Royalty right, but I'm really unsure about the Helepolis.
Another undocumented trick, originally intended just for debugging of the Diagram script: If you open the piece table, and click on the header of the move column, it switches to showing the guestimated piece values instead. And it also shows the (hexadecimal) value of the 'royalness' parameter for that piece, if non-zero. Using this it is easily confirmed that you made Prince and King both royal.
As to the Helepolis: combining 'transparent' and 'destructive' modes (such as m and c) in a non-final leg is something the old move generator (used only for the move diagrams if you specified newClick=1) cannot handle. For that reason it splits such moves during parsing of the XBetza descriptions. But the splitting only works for the first leg that needs it, as the old script could not handle more than a single locust capture in the first place. And for the Helepolis you have upto 14 mc legs...
But that is completely unnecessary. By basing the description on a Rook move instead of a Wazir, skipping of the empty squares becomes an implied possibility of each individual leg. So (caf)14R describes the same as (mcaf)14W (with the difference that the old move generator understands it too). What you did is a bit similar to defining a Rook as (maf)14W, making a separate leg out of each step. And that would be quite inefficient, as the modifier repetition would be handled by preprocessin the text description, expanding it to WmafWmafmafWmafmafmafW... Eventually the move generator, when it gets to generating the N-step move, would start testing the first N-1 squares to see if these are empty, while it already had obtained that information during the attempt to generate the (N-1)-step move. When described as R it would simply try to add another step to the last move it had, and once it encounters an obstruction it would be done with that direction, and never try any longer moves for it.
Another undocumented trick, originally intended just for debugging of the Diagram script: If you open the piece table, and click on the header of the move column, it switches to showing the guestimated piece values instead. And it also shows the (hexadecimal) value of the 'royalness' parameter for that piece, if non-zero. Using this it is easily confirmed that you made Prince and King both royal.
As to the Helepolis: combining 'transparent' and 'destructive' modes (such as m and c) in a non-final leg is something the old move generator (used only for the move diagrams if you specified newClick=1) cannot handle. For that reason it splits such moves during parsing of the XBetza descriptions. But the splitting only works for the first leg that needs it, as the old script could not handle more than a single locust capture in the first place. And for the Helepolis you have upto 14 mc legs...
But that is completely unnecessary. By basing the description on a Rook move instead of a Wazir, skipping of the empty squares becomes an implied possibility of each individual leg. So (caf)14R describes the same as (mcaf)14W (with the difference that the old move generator understands it too). What you did is a bit similar to defining a Rook as (maf)14W, making a separate leg out of each step. And that would be quite inefficient, as the modifier repetition would be handled by preprocessin the text description, expanding it to WmafWmafmafWmafmafmafW... Eventually the move generator, when it gets to generating the N-step move, would start testing the first N-1 squares to see if these are empty, while it already had obtained that information during the attempt to generate the (N-1)-step move. When described as R it would simply try to add another step to the last move it had, and once it encounters an obstruction it would be done with that direction, and never try any longer moves for it.