It wasn't actually quick.
I'd been mulling over how to fix the boss defeated event being interrupted by the player stepping on tile event triggers (for example, during the Dark Lich fight, stepping on the warp tile at the bottom edge of the arena). If the player steps on a tile that activates an event at just the right time, it can interfere with the generic boss defeated "Way to go!" event (which stops the music and heals the heroes), or with the boss-specific event that then activates shortly after the "Way to go!" event. When the latter happens, it can break the game and require loading a save, or at least loading a save state / emulator rewinding. Anyway, this meant that I had been looking at boss code so was slightly more familiar with it than I was previously.
When you asked about changing those bosses, I was literally looking at the Dark Lich's code at the time, so started checking out his AI logic. Here's a brief rundown of the logic:
So the original Dark Lich AI issues stem from a combination of underground + head showing + attack = do nothing, and the 20% chance to go above ground only being possible if the head is hidden. If he went underground, you stand east / west of him to make him show his head, then stand south / north of him so he only moves south / north, and when he attacks he does nothing, so he can never attack, never hide his head, and never go above ground.
Kethinov's original Dark Lich Head Bang Fix removed his ability to move south / north while underground, which meant if he tried to move, it was 50% chance of doing nothing, or 50% chance of showing / hiding head, which meant eventually he'd hit the 20% chance to go above ground when his head was hidden. The movement logic became:
Obviously that'd conflict with changes to make the Dark Lich move
more when underground, so first I rewrote this. Instead of disabling movement, I changed the attack logic, so that if his head was showing and he tried to attack, it'd hide his head and do the fist clench. Since it gave a mechanism to get back to the hidden head state, when it moved again, it'd have a 20% chance to go above ground, so that fixes the logic flaw that would let you trap him. So the attack logic is now:
With that resolved, I then needed to figure out how to make him move east / west while underground. The Dark Lich doesn't have any AI for horizontal movement while underground.
There's enough space in his AI table to add 4 more AI actions, and with some optimization, space can be made in his AI action scripts to add 4 more. But there's a problem: the Dark Lich has some animation lookup tables in bank $DC (0x1C) and they don't have room for 4 more AI actions. The relevant table is at $DCE4A9 which controls the Dark Lich's body animation while performing various AI actions. To make this approach work, I would have needed to either relocate something in bank $DC (to add 4 entries to that table) or change the Dark Lich's AI code to clamp the lookup in that table to its maximum value. Neither was very pretty. Besides that, if I had added 4-direction movement to either or both underground states (head hidden / showing), then what would trigger
changing head state (showing / hiding head)? I actually set this approach up enough to try it and just ignored the glitched out body graphics. It wasn't going to work well this way: there wasn't a good way to wedge the underground state change back in other than random chance or triggered by attack, neither of which was good. So I scrapped the addition of 4 AI actions and went back to the drawing board.
I reevaluated what was wrong with his vanilla AI to begin with:
- can only go above ground if underground + head hidden
- cannot attack if underground + head showing
- underground state changes if in non-movement direction
So I figured, if underground + head hidden = move south / north or state change, maybe changing the head showing movement from south / north to east / west would allow the full range of movement, but still give a means of changing state. So that was the first change: reconfigure his AI code and actions so that underground + head showing would move east / west, and if the target was south / north, then 50% chance to do nothing or hide head.
But the random 50% chance to do nothing or change state meant he wasn't very aggressive at chasing as he'd often stop and sit there if you simply kept to a non-movement direction, so the next change was to remove the 50% chance to do nothing. Now, if you were in the direction where he couldn't move, he'd immediately hide or show his head and continue moving.
After some testing, it became obvious that he was prone to overshooting. He'd move towards you, then beyond, then turn around and move, again too far, and then do the fist clench attack, but he'd have moved out of range. It was easy to stand where he'd just overshoot back and forth, and never land the attack, even if you didn't move.
I was considering increasing his agility so that he could attack a little more frequently, so he wouldn't bounce back and forth over you multiple times before the fist clench attack, but even with that change he could still overshoot his movement, and I didn't really want to also be messing with his stats as that would make other mods that want to adjust boss stats more likely to conflict.
It was when reviewing his agility that I whipped up Combat\Faster_Bosses to see how he'd behave if he could attack more frequently. It helps, but doesn't really solve the overshoot issue.
To fix that, I halved how long he moves when underground, from 0x18 animation frames down to 0x0C, which meant he'd recalculate movement twice as often and could home in on a player more accurately. Even if his attack timer wasn't ready and his movement bounced back and forth over a player, he stayed in range for the fist clench once he finally used it.
This meant he tried the 20% underground -> above ground chance check twice as often though which meant he was too likely to leave the underground state. So I simply halved the chance down to 10%. However, he still only could go above ground if his head was hidden, so I adjusted the AI code to do that check before checking the head visibility state, so now he can go above ground even if underground + head showing (the animation for this is "wrong" as his head abruptly vanishes but it's not bad enough to worry about). So the final result is:
So yeah, I spent hours on it. The "4 new AI actions" approach was day 1, and it was over dinner that I realized I might be able to divide up movement directions between the head visibility states, but didn't get a chance to try that until day 2.
Regarding the ZPS Patcher issue, I know basically what you're running into, but have never had it get completely stuck for me.
- Does clicking the X in the messagebox corner work?
- How about spacebar, enter or escape?
- If you uncheck the (Helper_Script) checkbox and patch, the "Finished !" messagebox can be interacted with normally, correct?
- When that messagebox is showing, can you press Ctrl+C, hear a ding sound, then open Notepad and Edit\Paste, and have it show a copy of the text that was in the messagebox?
- Is Ctrl+C even your "Copy" hotkey combination?
I suspect the Helper Script is jamming up the "Finished !" messagebox somehow. Did it used to work correctly for you? I do occasionally try and improve the Helper Script and there were some changes made to it back when commandline support was added to the ZPS Patcher itself.