Resurrection

The 'limiters' I introduced on actions like capture or hop did allow general probing for an activator in the environment, such as needed in Knight-relay Chess: just start in any direction to see if you find a friendly Knight to hop over with a 'bouncing hop' (dismounting it on the same side as you mounted it, t{N}N-bN, and then continue with a Knight move. This is something like a programmer's OR operation: the piece can do the final Knight move if in any one of the eight directions it probes for a Knight it finds one. It is in fact a multi-path move: you have to find your way over a Knight first before you can do anything, and all possible paths along which you are allowed to do that eventually merge to end on the same square.

The opposite of an activator is an inhibitor, like the Ultima Immobilizer. It would be nice if the notation could also handle such kind of pieces. But the logic is opposite: all squares in a certain neighborhood should be free of Immobilizers, not just one. For an inhibitor that would only prevent its neighbors from moving radially away from it, it would be easy. You would just write a prefix mtop{!I}K-bK- in front of the moves of pieces that could be affected by it. This would force the move to begin with a K step (in the opposite direction of where you would eventually end up) and then back (-bK), which would succeed if you (1) found an empty square there (m) (2) found a friendly piece and hopped over it (t) (3) brought you off-board to quickly retract the step (o) (4) found a piece to hop over that is not the feared immobilizer (p{!I}). But making the same probe in all directions to handle an omni-directional inhibitor, by decoupling it from the direction of the eventual move by prefixing the latter with an a does not work: It would allow the move if there is any path that avoids the immobilizer, immobilizing only pieces that would be completely surrounded by immobilizers...

It turns out that the notation as proposed can already handle this, provided we adopt a new convention. This convention is that the fragments ejected by an eruption specified by the x modifier are allowed to come together again, to resurrect the exploded piece. This resurrection would only succeed if all the fragments would coalesce. If only a single one would be missing, the resurrection fails, and the move is aborted.

This convention allows us to test for an adjacent immobilizer by a prefix xmtop{!I}K-bK-a. The logic for each individual fragment is the same as before: it can return to the initial square (where the explosion took place) in all cases except when it would have stumbled on an Immobilizer. But if one of the fragments does, because you were indeed sitting next to an Immobilizer, its path is blocked, so that it will not return to the explosion square, and resurrection there will fail. Without adjacent Immobilizer resurrection succeeds, the fragments become the real piece again, and continue the rest of the path as real move. (The a direction al modifier specifying that the move can go in any direction. Perhaps this should be implied after resurrection, as the previous step has no unique direction, fragments coming in from all directions, and is basically a null move. So what is 'forward' after this can only be defined in relation to the step before the explosion. And as the explosion was the first step here, this would mean the initial directional spec for the entire path, which by default is a.) If resurrection fails, because one of them did not make it back, the fragments evaporate as usual. They are 'rounded down' towards zero, as it were.