It sounds like something in your code is producing an unwanted goto to the beginning of the program when the E piece is moved.
That is totally unexpected behavior, and makes it virtually impossile to figure out what the error is. Isn't it possible to do some syntax checking on the GAME code (e.g. when it gest submitted) to prevent such erratic behavior?
@Daniel: You redefined the Promote routine just to implement Shogi-style promotion? Perhaps the betza.txt include should already provide a standard way to do that. E.g. triggered by the presence of an associative array #shogiprom, which would provide the promoted type when indexed with the basic type, and then set #choice to an array containing that promoted type and the piece itself. This could still be intersected with the possible choices for each rank (e.g. to suppress deferral for Pawns on the last rank, or Shogi Knights on the last two ranks). But it could probably bypass intersection with the captured pieces plus supply, as promotion to captured pieces only seem to make no sense with Shogi promotions.
That is totally unexpected behavior, and makes it virtually impossile to figure out what the error is. Isn't it possible to do some syntax checking on the GAME code (e.g. when it gest submitted) to prevent such erratic behavior?
@Daniel: You redefined the Promote routine just to implement Shogi-style promotion? Perhaps the betza.txt include should already provide a standard way to do that. E.g. triggered by the presence of an associative array #shogiprom, which would provide the promoted type when indexed with the basic type, and then set #choice to an array containing that promoted type and the piece itself. This could still be intersected with the possible choices for each rank (e.g. to suppress deferral for Pawns on the last rank, or Shogi Knights on the last two ranks). But it could probably bypass intersection with the captured pieces plus supply, as promotion to captured pieces only seem to make no sense with Shogi promotions.