I more or less finished implementing Makromachy. (Some imperfections in the graphics remain: the two 3d Cannons use the same 2d image, and I still want to distort some of the 3D pieces.) Only three moves were not implementable through the graphs and flags offered by fairy-move-model.js: the Fast Castling (K jumps to any empty base-rank square, and R to the K-square), the Airlift Moves (slide up to the first piece on the ray) of Knight, Elephant and Champion, and the Warrior backward captures (because they should not have e.p. capability, while the forward captures should). These required defining the moves as 'candidate moves' only, and implementation of a customGen routine to 'mature' these candidates to push them to the moves list.

To this end the Warrior backward captures are defined with FLAG_SPECIAL_CAPTURE. Because the Warrior has the epCatch property, these candidate moves are also generated when they go to the (empty) e.p. square. The customGen code for Warrior moves then tests whether the capture victim of the proposed move is indeed at the destination square, and discards the move when it isn't.

The Fast Castling is handled by defining a duplicat type for the corner piece, which as extra moves from the corner square have a direct jump to the King's starting square, with FLAG_CAPTURE_SELF modality. As soon as they move they 'promote' to a type that doesn't have these moves in its graph. (The standard way in which Jocly handles initial-only moves, such as the Pawn double-push.) When these candidate moves are delivered to customGen it has to be checked whether the piece they 'capture' has moved. (If not, it must be the King, and the corner pieces themselves cannot have moved either, because then they would have lost the move.) And whether the side to move is in check, which would also be a show stopper. If both tests are passed, the base-rank is scanned for empty squares, and for each of those a castling would be pushed, describing King origin and destination, and 'rook' origin. (As Jocly encodes castlings. The 'rook' destination is taken from the castling table in the game definition, and thus must be the King square here.)

The Airlift Moves were most troublesome, in particular the fact that a minimum distance is required. The makromachy-model.js file contains its own routine for generating the graph, which is similar to cbLongRangeGraph, but generates the first two destinations on the ray with FLAG_STOP, and those further away with FLAG_SPECIAL_CAPTURE|FLAG_CAPTURE_SELF modality. This then produces candidate moves that end on the first piece they meet (whether foe or friend). The customGen then modified the destination to the previous square on the ray (which is always encoded in candidate moves).

The customGen routine distinguishes these cases by the abbreviation of the moving piece (which is always included in (candidate) moves).

The ban on capturing protected Terrors with Terror or Eagle is implemented by giving these pieces an antiTrade property (2 for the Eagle, 3 for the Terror, so that the Eagle itself is not protected). minimumBridge is set to -1 to activate this. (As there is no double capture in Makromachy itsactual  value has no effect, as long as it is non-zero.) cbPawnTypes is set to 6, to make Pawns (initial and other) and Warriors (of both colors) reset the 50-move counter.

The ban on repeating a position through an Eagle check is implemented by setting cbMaxRepeats to 2. This already triggers the repetition logic on the first repetition. The makromachy-model.js contains a routine cbPerpEval that is then called. This tests whether we are in check, and if so whether the preceding move was an Eagle move, and adjudicates a win in that case. In other cases it test the repetition count; if it is 3 it adjudicates a draw, if it is 2 it refrains from adjudicating by returning undefined.

The only rule left unsupported, of which I am not sure how I can implement it, is that Eagle checks and the following evasion should not increment the 50-move counter. This counter has always been a weak spot of Jocly; the current master branch doesn't even reset it on Pawn moves. I made it slightly controllable through the introduction of cbPawnTypes, but it would be better if I fudge in some way for the game's model to manipulate the counter in a more intelligent way. Perhaps by providing a routine for it, so that you could adapt it in an arbitrary way.

The result can be tried at: http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=makromachy

[Edit] Oh, and I had to assign a King graph with FLAG_MOVE modality to Model.Game.neighbors, for correct implementation of the Terror's hit & run capture: this does not allow double capture or rifle capture, as would have been the default for moves that use the FLAG_HITRUN modality.