Possible solution to the sap death bug

Hey, thanks for the detailed reply -- that was a good read! Let me comment on a just a few pieces as I try to unwind all this code in my brain.

Whittle away much of each monster's HP.  kill one of them.  its Quake will kill the others, it'll revive itself, another one will counter with Quake and revive itself, etc., etc.  an infinite loop until they run out of MP!

This is a really good example of how my initial code snippet could go horribly, horribly wrong. Though to be honest, it's something I might be comfortable living with, if only because a monster that revives itself upon death will always need to run out of MP before the battle ends, anyway (unless, I suppose, if you want the player to run away, or use some specific means of avoiding the death counter, like Snare or insta-kill stuff). In this example, I think it may be more appropriate to consider the reactive script itself to be the bug. Maybe.

QuoteEdit: On second thought, this would still function correctly, as Enemy B's next Sap tick will trigger its reactive script, due to $3A56).

will C2/5018 allow this?  i think the omni-counter might have to wait until *another* entity's periodic damage/healing occurs, or an entity takes a normal turn.

Even if $5018 aborts the command, I think the calling routine will still proceed to the "prepare counterattacks" routine (at $140C), which will check for newly dead entities anyway.

4)

regarding your C2/4C5B changes: does your alternate code change any functionality from your first, shorter code?  i can't readily tell.

The alternate code does have one additional side effect -- that `B8/B9` is not set for counterattacks triggered by other counterattacks. However, I think that since counters are not meant to trigger other counters under normal circumstances, this is potentially a plus. So if a death counter is triggered by another counterattack, the death script will proceed as though the death were caused by a sap tick, and will randomize targets if necessary.