Very well.  My code-fu is strong.  Wise man say, “If cannot start from problem and work backwards, grasshopper, set breakpoint right before problem and work forwards.” Well, thanks a bunch, wise man, but that’s kind of a circular definition.  To know where “right before” is, I have to know where the problem itself is, which is what I’m trying to find out.  And the fact that it’s in a script only makes things worse–the script engine does all sorts of strange things.  So I look at the original event script in RM2K and watch what’s going on on screen, to see what steps I know have actually executed.  Then I notice something very strange in the event:

Move Event: Hero

That’s odd.  It usually displays the movement data.  I look closer and… there is no movement data.  Just “Move Hero”.  No movement commands.  Oh, and the little “repeat action” box is checked.  So not only does the hero do nothing, (as opposed to simply not doing anything, which was what he was doing before,) he continues doing nothing forever… until about 4 lines later, when “Move Event: Hero Down” shows up.

This must be the work of a very cunning ninja, laying a trap for me.  I must proceed carefully.  I set my breakpoint with caution in the routine that handles event movement.  I trace the whole thing very carefully in the debugger, and…

Access Violation Exception

…a swift karate chop from a different thread of the program blindsides me.  The error’s not coming from here, where the data’s being processed; it’s coming from the place where the movement command to do nothing is being carried out!

When my head clears and my program resets, I wearily drag myself to my feet and reset my breakpoints.  This glitch’s skill is great.  But my code-fu is stronger.  I search carefully for the problem, narrow it down to one subroutine…

Access Violation Exception

…I stumble to the ground, blinking back tears of pain and shock.  There it was, right behind me!  But when I turn around… nothing.  The ninja had struck and fled, and I still had no idea what the problem was.

In the end, I never did manage to figure out what was causing the access violation.  There doesn’t seem to be anything wrong with the data that gets generated; the system’s just handling it in a very strange way.  But wise man say, “If cannot track down exact location of glitch, cut off earlier.”  So I went back into the routine that generates movement commands and had it watch for that particular “do nothing forever” ninja.  If it runs into it in the future, it’ll simply turn off the “loop forever” flag, so the character will do nothing once, and then go back to… well… not doing anything, like he was doing before.

The RPG Maker item data structure has a list of flags representing which conditions the item cures. But since most items don’t cure any condition, the program saves space in the file by simply skipping the entire list if the whole thing’s set to false. In my code to read the data structure, I accidentally had it set the entire set to true if the list was missing from the file. So an ordinary item, such as a potion, suddenly becomes a cure-all item.

But it gets worse. Characters can be afflicted with various conditions, as defined by the game writer, and one condition that’s hard-coded into the system: “dead”. If a character’s dead, it changes a bunch of the code for his behavior. (For example, he can’t be healed while dead.) In the code to set a character’s condition, I had a check for whether the condition being set was condition #1 (dead), and if it was, to set a couple other things in the hero’s data structure relating to being dead. Unfortunately, this check didn’t look to see whether the “dead” condition was being turned on or off.

You can probably see where this is going. I tested out a potion on a hero, and… he died?!? That confused the heck out of me, of course. Turns out the potion (with the “cure condition” attributes set to all true) had tried to cure the hero of being “dead”–for technical reasons, it’s more efficient to simply set the condition to false than to check whether it’s set and then only set it if it’s already true–and this set off the special code. So instead of getting healed by 50 HP, the hero died. Huzzah for Potions of Death!