I think the hopper moves are now properly implemented too. I had to make an innocent extension to the standard script, making the move generation remember the location of the latest mount used by a hopper, so the Tinker routine could use it. (Only done when the captureMatrix contains a hop ban, so for most variants no slowdown at all.) I also had to alter the way 'primed' moves were exempted from morphing and capture matrix, so that it would not exempt them from a custom Tinker script as well.
This enabled the custom Tinker routine to test whether the proposed capture of a Giant was made by a hopper, and if so, whether the mount was that same Giant. If so, the move is rejected. This prevents the normal hops cpB and cpR to 'backstab' a Giant. To hop the Giant an extra move pyafpyafcB or pyafpyafcR was added, and the captureMatrix was used to ban hopping over other pieces than Giant (but priming the single hop so that this ban does not apply to it).
The only thing that still doesn't work is promotion to Dev. I am not sure this is worth worrying about. This promotion is a bit ill-defined anyway. (What if there are opponents in the area where the Dev should materialize? Are these captured by the Pawn move?)
Other issues: It is also unclear whether the pieces that provide 'capture assist' by threatening the Dev should do this by pseudo-legal or by legal moves. I assumed pseudo-legal. 'Castling as in orthodox Chess' is impossible, or at least ambiguous, as the Rooks are further away here. Does the King move as in FIDE (i.e. two squares), or the Rook (i.e. producing the same final position as in FIDE). I assumed the latter. Can both Rooks on the back-rank castle, or just those in the corner? (Again I assumed the latter.) Why promotion on the last two ranks? The Pawns only move in steps of 1 there, and they never can get to 16th if they already promote on 15th. Even if they would be allowed to defer there, no one would do that.
I think the hopper moves are now properly implemented too. I had to make an innocent extension to the standard script, making the move generation remember the location of the latest mount used by a hopper, so the Tinker routine could use it. (Only done when the captureMatrix contains a hop ban, so for most variants no slowdown at all.) I also had to alter the way 'primed' moves were exempted from morphing and capture matrix, so that it would not exempt them from a custom Tinker script as well.
This enabled the custom Tinker routine to test whether the proposed capture of a Giant was made by a hopper, and if so, whether the mount was that same Giant. If so, the move is rejected. This prevents the normal hops cpB and cpR to 'backstab' a Giant. To hop the Giant an extra move pyafpyafcB or pyafpyafcR was added, and the captureMatrix was used to ban hopping over other pieces than Giant (but priming the single hop so that this ban does not apply to it).
The only thing that still doesn't work is promotion to Dev. I am not sure this is worth worrying about. This promotion is a bit ill-defined anyway. (What if there are opponents in the area where the Dev should materialize? Are these captured by the Pawn move?)
Other issues: It is also unclear whether the pieces that provide 'capture assist' by threatening the Dev should do this by pseudo-legal or by legal moves. I assumed pseudo-legal. 'Castling as in orthodox Chess' is impossible, or at least ambiguous, as the Rooks are further away here. Does the King move as in FIDE (i.e. two squares), or the Rook (i.e. producing the same final position as in FIDE). I assumed the latter. Can both Rooks on the back-rank castle, or just those in the corner? (Again I assumed the latter.) Why promotion on the last two ranks? The Pawns only move in steps of 1 there, and they never can get to 16th if they already promote on 15th. Even if they would be allowed to defer there, no one would do that.