I saw the "EVENT DATA" in the ZPS, and I'm sad to say that I didn't really fully understand all of it.
Plenty of it isn't obvious or is nearly contradictory. In time you'll wrap your head around more of it.
I understand the labels, but I don't understand how those labels are translated into actual specific addresses. I mean, I get that it's connected to a particular event, but which part of the specific event?
Any event label that isn't the standard Event### (so any that are like Event###.Patch_Name) the patch author (namely, you or me) places in the primary event scripts.
For example, search the Turbo ZPS file for "@OFF Event065.Neko_Distribution_Network.goto" and you'll find it in 3 places: the Relocalized, VWF and Vanilla primary event scripts. Here's what the Relocalized Event065 looks like:
@OFF Event065 ' $E11506
TEXT _ ^P u r r f e c t l y _ p r i c e l e s s \n
TEXT _ i t e m s _ a v a i l a b l e ! \n
TEXT _ _ ( _
\event \text_opt_start \text_opt_define= 04
TEXT ^B u y _ _
\event \text_opt_define= 09
TEXT ^S e l l _ )
\event \text_opt_end== \goto 311
\event \goto 301 \goto 313 \end
Note how @OFF Event065.Neko_Distribution_Network is just before \event \gold_show and @OFF Event065.Neko_Distribution_Network.goto is just before \event \goto 301; I added those labels in the same spot for all 3 scripts, so when you use %OFF% Event065.Neko_Distribution_Network and %OFF% Event065.Neko_Distribution_Network.goto, it overwrites \gold_show and \goto 301 (with \call 088 and \goto 312, respectively).
There's nothing automatic about adding the labels, you just go add them, and then use them in your patch. If all three primary event scripts get the same label added in equivalent spots, then your patch can use a single %OFF% Event###.whatever label to make the same change regardless of which event script is active (as long as you avoid altering text, pretty much). With the upcoming addition of the Script Augmentation Project, it will require adding the label(s) to the right spot in it as well, but that should be far less painful than byte pattern searches.
I saw the Neko Distribution Network part that was commented out (it uses the event088 for Ice Neko, instead of creating a whole new event 649). I don't know how that will work, but if that works, then yes, I'd prefer to your link to event 088 (I want to avoid creating new events if I can avoid it). Having said that, wouldn't that screw with Relocalized?
Ice Neko is weird and doesn't open the gold display right away, so it calls different events that open the gold display before the buy / sell menus (and calls a save event that doesn't close the gold display since it isn't open). My changes just make Ice Neko like the others so it opens the gold display right away and then uses the typical Neko set of events for Save, Buy and Sell.
I don't actually understand your concern regarding Relocalized (or VWF, etc.) and space. If this is just related to Event178, VWF (and so Relocalized) use some events that were unused in Vanilla, and 178 happened to be one of them. The Neko events in VWF and Relocalized are barely changed so space constraints are generally the same for them.
I also noticed that you used event 312 (uses the IF events) instead of 310 (just calls the shops).
Event310 is a generic Buy / Sell dialog that then goto's 312. Ice Neko only calls 310 because 310 opens the gold display.
A side note: For Aborted Dialog, when Luka is locked in her own dungeon, she has that one-time dialog (similar to how moogles have that one-time dialog in the Upperland). Perhaps you'd make it so that it's not abortable?
Whoops, yeah I shouldn't have made this one abortable.
Jeez. I've been going through all of the events to see if there's anything I can use for Dispel Inn, but I can't find it at all. Apparently, a never-before-seen event would have to be created, and I have no idea how to do that. There's events called, "\heal_all", "\cure_all", and "\refresh_hud" (not sure what that last one is), but I have no idea how to use them to create the dispel effect.
Yeah, that's why I didn't get that implemented yet. It's unfortunately not simple.
\refresh_hud means... well HUD is heads-up display, and is referring to the UI at the bottom of the screen that shows your health, stamina, etc. Refresh in the context of software interfaces usually means to redraw it because something changed. So that command makes the UI at the bottom update after changing player health via script (like via \heal_all). If you change the player's health but don't issue the \refresh_hud command, the player's health may not show the updated value until something else causes a HUD refresh (like taking combat damage).
The \stats1 commands let you manually set various values in the top 0x100 bytes of player stats, which include stuff like status effects (90 and 91), buffs (B0), and so on. So it's probably possible to do the same things dispel does via events, it's just tedious and will likely take up too much space to try and cram into an unused gap.
Dunno what other sources there are.
reconstructingmana is pretty much the expert on what Secret of Mana lore is out there. While I like their Mana Redux blog in general, I think https://manaredux.blogspot.com/2019/04/early-world-maps-redux.html
is an especially fun write-up.