FF6AE

With Monster AI scripts, you just have one pointer table to look up and see where they start (of course you have to run until you hit the second FF after that to know where it ended). Also, each command has a fixed length in bytes, from one to 4, and there's a table for that also. The command is the first byte, and there's no change-of-context to worry about; if it's F1 = target type here, then it's F1 = target type there. It's relatively straightforward, but yes, variable in length which is of course harder than something like Shop data or something which is just straight up fixed numbers of bytes.

On the other hand, Event scripts are a real bugbear. You have a lot of different issues. First off, there is no central lookup table for events. They can be called from Tile Triggers (most common), NPCs (also fairly common), other events (subroutines), hard coded assembly when using certain items (tent, anyone?), and map entrance events (which, when coded correctly, have to have various branches for any changes you may have made to the map-specific temporary event bits).

And there's nothing stopping one event from starting in the middle of another one. That can happen, and I'm pretty sure it does in at least one case.

To make matters worse, event commands are not fixed in length. MOST of them are, but some of them are not. For the ones that are not, you don't know until you read some of the parameters for the command. Which means you can't just arbitrarily read a few bytes ahead and reliably know the commands. If you've tried to write a disassebler for the SNES's processor, you know what a pain the REP/SEP tracking can be, and how easy it is to get incorrect results. The event code is the same way.

Oh yeah, and event code is chock-full of context switches. That's because some of its commands actually spawn a whole other script. Not just one other script, either. There's a script for character event queues, which most people know. There's also a vehicle script, which tells it how to move the airship (or Terra sprite, or bird, or whatever) or a camera pretending to be an airship over the world map. It can also load other maps, but it uses a different byte to do so. Then there's another script, which is rarely used but simulates walking on the world map as a character (this is distinct from non-world-map walking a la the charcater event queue).

To fully handle events properly, you have to, at a minimum, know how to detect all of the above issues. And oh yeah, one other thing: Sometimes an event (or branch within an event) will start off in one of these odd contexts. This is why my event dump has a few hard-coded points where it just had to 'know' that it's in a different context, and if you get an older copy of that dump you'll see that I missed a few before I figured that out.

Seriously, it would almost be easier to pass the whole event system through a separate lookup table (that is, recode it so that instead of addresses you just get an index to a pointer table). It would add a lot of bulk, yes, but it would be so so much easier to maintain.