Comments/Ratings for a Single Item

I think it did, at least partly. But it is not obvious, because the I.D. does pseudo-legal highlighting, and the capture restriction on Terrors is a context-dependent rule that results in some pseudo-legal moves to be illegal. If I set up a position where the AI can gain a Queen by trading Terrors (TxT, QxT, BxQ), it does not capture.

The I.D. in the article had configured the rule the obsolete way, though, through a protected=32 parameter. This could not specify the 'asymmetric' version of the rule, which forbids Eagles to capture protected Terrors, but not Terrors to capture protected Eagles. I changed that now by using the captureMatrix for specifying the forbidden cases by marking those with a % sign.

The betza.txt include file currently also doesn't support asymmetric anti-trading; the I.D.'s anti-trading through the protected parameter is implemented there by initializing an array

set protected (...);

which lists the labels of all pieces mentioned in protected parameters. But it then bans all captures of the mentioned pieces by each other (when protected). So if both the Terror and Eagle go in there, T x protected E would also be forbidden. I suppose I could fix this by having the betza.txt include use two attays, 'protected' and 'restricted', and then ban only the captures of a piece mentioned in 'protected' by one mentioned in 'restricted'. When the PTA translates an I.D. that contains protected= parameters to GAME code, it could then define both arrays with the same pieces in them (where it now only defines 'protected' in the Pre-Game code).

More precise definition of what can capture what will have to wait for full implementation of the captureMatrix in the generated GAME code. But in most case (including Megalomachy) such a temporary fix would be sufficient.

[Edit] I now modified the betza.txt include file to support these changes. So in Pre-Game you would have to define an array 'opaque' with the flying pieces and those that can shoot them down, an array 'protected' with the Terror, and an array 'restricted' with Terror and Eagle.

The author, H. G. Muller, has updated this page.

I'll do it today!

I think the Terror would not be problematic for the automatic conversion

If I'm reading the rules correctly, the ID doesn't handle the capture restriction for the Terror.

Might it work to use the generated code for most of it and manually define the pieces that wouldn't work?

I suppose this would be an option; the 'Custom Pieces' section of the 'Wizard for GAME-code generation' article described how to add pieces that would need explicit programming. I think the Terror would not be problematic for the automatic conversion; it is the flying pieces that would need separate coding, in particular their jump-capturing moves. I suppose you could define thir moves in the I.D. as QK, RW and BF, and then replace the K, W or F moves by a routine for generating jump-captures in the described way.

But it might be simpler to clone the betza.txt file, and modify the move generator there with some dedicated code for this variant. And then use this modified version instead of the standard betza.txt in the preset. All that would have to be done is to insert some code at the point where it now is decided that an encountered piece can be hopped over by a test whether both pieces belong to the set {bat, eagle, raven, archer, spearman}, and abort the generation of that hopping move when they do.

Since this code would only be invoked when a hopper move hits a potential mount, it would not slow down the move generation very much, and I could even insert that in the standard include file. Then all what would have to be done is defining the pieces that cannot hop over each other in the Pre-Game code, like

set flying (...);

where the ... would be the list of labels of all the pieces (of either color) to which this applies.

I thought that might be the case. They don't seem too different from pieces I've done before with GAME code. It's the Terror that looks most difficult, actually. I have not yet managed to comprehend rule enforcing for multi-moving pieces.

Might it work to use the generated code for most of it and manually define the pieces that wouldn't work?

Don't count on automatic conversion of the Interactive Diagram to GAME code, though. There are some aspects of this variant that are not supported yet by the betza.txt include file that powers such GAME code. In particular the captureMatrix, which is used to make the flying pieces block each other.

One of us could make it. I'm interested in trying this too

I can't find the game courier preset. Is there one?

It could be a fun game. Maybe I'll try it these days!