Some Quirks in RPG Maker 2000's Event Loop

I have been using RPG Maker for like 23 years now. You'd think after all that time I'd know the ins-and-outs of its eccentricities. Yet somehow I keep finding — or remembering — new and curious things as to how it handles some stuff.

For the most part these are things I simply never ran into because I've designed/coded around them, or I've compensated for these quirks without realising it. But recently I tried doing some things only to find them behaving in ways I didn't expect, which then lead to a rabbit hole of realisations. So I thought I'd share some of that.

These probably also apply to RPG Maker 2003, but I haven't tested that. These almost certainly don't match EasyRPG's reimplementation, at least as of writing. This is specifically from the official english release of RPG Maker 2000 1.62.

• Erase Event does not stop an event from processing, it will continue until it finishes its current page. For actual event halting you need End Event Processing. An Auto Start also keeps going after it's erased just like a standard event, but will no longer loop, stopping once it ends the current page.
  • Except if it's a Parallel Process. A Parallel Process will stop the moment it's erased.
  • It's possible to call an erased event. This isn't too much of a concern, though it may have limited application. I've used this myself to re-run an erased Parallel Process.
• End Event Processing will end an Auto Start or Parallel Process's current page loop, but doesn't halt the event.
  • Yes, if you're keeping track: for player triggered events, Erase Event won't stop the event right there, but End Event Processing will. Meanwhile for Auto Start and Parallel Process, Erase Event kills a Parallel Process immediately, queues up an Auto Start's death, and End Event Processing merely ends a present loop. You can see how I may have been thwarted by these quirks.
  • Generally speaking Erase Event is a dirty method and you really want to be handling "killing" events with Switches and Variables, but that's beyond the scope of this post.
• Changing a condition that should take priority in the page order (eg. turn on Switch 1 mid-event, and page 2 uses Switch 1) does not stop the existing page from processing, and it will continue that page before starting the next one if Auto Start or player triggered.
  • Except if it's a Parallel Process! If page 2 is a Parallel Process it interrupts page 1 the moment it's valid. Page 1 keeps going too, thus it's possible to have an event running two of its own pages at the same time. Identical event commands on page 2 override page 1 (eg. different coloured screen flashes), and the highest priority Parallel Process page is the only one that will run in parallel to the initial page.
• Auto Starts do not halt player input if they are "doing nothing". An empty Auto Start, for example. A function that's not moving events or internally waiting (Move Picture, Tint Screen, Key Input Processing, etc., without wait setting) also don't prevent opening the menu, but do still stop movement.
• Auto Starts also have a slight delay to triggering, whereas a Parallel Process will run once a map has loaded, before the screen transition.

Consequently it can be argued that while Auto Start and Parallel Process are superficially similar in application — they both trigger automatically — their intended use case are actually quite different! An Auto Start can be compared to a standard event in that as long as it's running, it functions just like a normal event down to not halting input if it's "doing nothing". A Parallel Process however is meant for pure background behaviour.

You might be thinking "well, yeah, that's how everyone always used it" but have you ever actually analysed why? We all just took it for granted that Parallel Process events are for background fluff, but the nuances to how they trigger and how they halt not only emphasise this purpose even more, it makes it clear how Auto Start should be used for actual "scenes", not Parallel Process.

I wonder how much obfuscation was introduced by Don Miguel's original translation, back when I was using that in the mid-2000s. I'd have to dig out the original editor to see what he called Erase/Delete Event and End Event Processing, but I'm almost certain the first version didn't even name Erase Event properly. For that you needed a patch.