I guess I forgot to have the callbacks for the Shogi promotion (on the yes/no message) call the new handler for finishing the move.
Should be fixed now.
As to documenting the WeirdPromotion / BadZone scripting stuff. So far I have refrained from doing that, because writing their own JavaScript would be beyond the capability of most prospective users (present company excluded), and dwelling too much on it in the description of the Diagram is more likely to discourage people from using the latter than to help them.
But there are other reasons as well: this part of the Diagram is pretty much experimental and still in development; I already changed the parameters used in the function calls several times, and even the current argument list of WeirdPromotion is not well suited for the new move-entry system, as it only a single e.p. square. I now also regret that WeirdPromotion and BadZone are separate functions. It would have been quite possible to have their tasks shared by a single function, which, when called with the full description of the move, would return whether the move should be rejected, result in game termination, change the piece type in a mandatory way, or offer promotion choice. And in the latter case it would be desirable if it could actually specify what can be chosen. E.g. by returning a string in the format used for promoChoice, overruling the latter.
And I actually consider it an embarassment that such scripting is needed at all. Ideally it should be possible to specify the rules solely through Diagram parameters. The newly introduced parameters morph and captureMatrix make a great step in that direction; these are very powerful features, which could satisfy the requirements for the large majority of Diagrams for which I originally had to write WeirdPromotion aor BadZone functions.
I guess I forgot to have the callbacks for the Shogi promotion (on the yes/no message) call the new handler for finishing the move.
Should be fixed now.
As to documenting the WeirdPromotion / BadZone scripting stuff. So far I have refrained from doing that, because writing their own JavaScript would be beyond the capability of most prospective users (present company excluded), and dwelling too much on it in the description of the Diagram is more likely to discourage people from using the latter than to help them.
But there are other reasons as well: this part of the Diagram is pretty much experimental and still in development; I already changed the parameters used in the function calls several times, and even the current argument list of WeirdPromotion is not well suited for the new move-entry system, as it only a single e.p. square. I now also regret that WeirdPromotion and BadZone are separate functions. It would have been quite possible to have their tasks shared by a single function, which, when called with the full description of the move, would return whether the move should be rejected, result in game termination, change the piece type in a mandatory way, or offer promotion choice. And in the latter case it would be desirable if it could actually specify what can be chosen. E.g. by returning a string in the format used for promoChoice, overruling the latter.
And I actually consider it an embarassment that such scripting is needed at all. Ideally it should be possible to specify the rules solely through Diagram parameters. The newly introduced parameters morph and captureMatrix make a great step in that direction; these are very powerful features, which could satisfy the requirements for the large majority of Diagrams for which I originally had to write WeirdPromotion aor BadZone functions.