Single Comment

I think the Interactive Diagram now completely implements the rules as I understood those. To make this easy to achieve with the custom Tinker script, I had to make a few modifications in the standard betzaNew.js script powering Interactive Diagrams. In particular how it handles exemption of moves from the effects of morph and captureMatrix by dressing those with an apostrophe in the XBetza move descriptor, and how it resolves conflicting instructions specified in these two:

For one, the apostrophe now does not prevent a custom Tinker script for being applied to the move. If it is desirable that such a script only affects part of the moves, it can always be made smart enough to make that destinction itself. But it was inconvenient that moves that should excluded from the specified morphing/banning could then not be adapted in other ways (such as adding an unload on their origin square).

And I think I provided a more natural way to resolve conflicts between morph and captureMatrix: if the captureMatrix specifies a type change, it is executed first (even if the morph for the moved piece would have specified a different type change). But then morphing is applied according to the morph for that resulting type, rather than the original piece. This made it possible to implement the Turnover promotion rules by having Pawn and King morph into Queen on the last rank; even when a piece that was originally (say) a Knight 'unstacks' to split into a (moving) Pawn and a (remaining) Bishop, it is the arival of the Pawn (or the transformation that it brings about on a turnover victim) that triggers the promotion.

This behavior can be controlled with maxPromote, as it only applies to pieces that are not specified as promoting (the promotion purely controlled by morph, not by promoZone). For promoting pieces a morph specified for the moving piece would cause the captureMatrix to be ignored. (And one can always suppress promotion by zone for those pieces by setting promoZone=0.)