Version 2019-08-08:
https://ufile.io/l9h9dhcxChanges:
- Slight tweak to Kethinov's "Magical Herb" hack to invalidate targeting dead players (I forgot the "+" symbol in the feature description)
- Quality_of_Life\Boy_Dislikes_Nuts; can no longer use Faerie Walnuts (or Coconuts) on the boy, and before anyone has magic can't use them at all
- Bug_Fixes\Initial_Distance; properly initializes some NPC data, primary result is you can no longer interact with an NPC from long range when they spawn
- Graphics\Polished_Weapons (Whips & Flails); fixes alignment issues on some Whip animations (for example, boy sprinting left / right) and adds a secondary animation set for Flails
- Tidy Map treatment for the final whip room in the Grand Palace; fixes some erroneous stained glass and shadows at the top of the room and provides some escape routes if you try and get stuck using whip post jumps
Technical Changes:
- Added ending credits text roll characters to the character table (it's just limited ascii)
- Minor Combat\Strong_And_Weak_Attacks code reorganization (and elsewhere in &(mods)\Combat)
- Small NOP optimizations here and there
- Fixed a dependency between DEBUG_MODE and Combat\FastNumbers
- Fixed detection of X button by DEBUG_MODE and added support for animation testing (via R+X; 0x000-0x0FF all PCs, 0x100+ boy, 0x200+ girl, etc.)
Polished Weapons (Whips & Flails) took me more than a week to change just a single weapon (though I'm happy with the result). I'm hoping that other weapons will take less time, as some of that was spent on learning and tooling, and on building the infrastructure for custom weapon animations. I had toyed with the Flails having different collision areas for one of their attacks but nothing I tried was both "fun" and side effect free (lots and lots of issues with whip posts).
ShockwaveS08B1) I think this has to do with which phase in the 5-frame cycle the boy's code runs versus when the UI updates. Something I want to fix because it's sloppy, but will likely take some digging.
S1) Erm, while that would be neat, it would be a massive undertaking. I'll give a longer explanation later (because it's a fun thought experiment).
S2) The waypoint idea would be super useful... it's probably not possible but I've already had a couple thoughts pop into my head on stuff to check as long shots.
S2b) Changing the "globe" scrolling speed is probably not possible; in that view, rotation is fast because it's using SNES hardware graphics rotation to just spin what is already loaded, but scrolling requires rebuilding the entire "globe" image with each movement step. Because you're scrolling in an arbitrary direction, you can't jsut slide what data is there and add onto the end; you have to throw out the old and load a new image based on the new resulting view location.
S3) I'd love to, that's been on my long term to do list since I started on this project. Its absence after 8 months should make clear, very non-trivial to actually do.
S4) Please try what I have before making wild guesses as to what is and isn't necessary for New Game Plus; I've already accounted for most of what you bring up, and generally less destructively than you suggest.
Q1) Like vivify93 and lexluthermiester already brought up, Secret of Mana has always had three player capability. On a real SNES you use the multi-tap in the controller two port (SoM throws an error message if you try to use it in the controller one port); in most emulators you need to have multi-tap emulation enabled and controls defined for controllers 3 (and 1 and 2, obviously) though some emulators do not support 3+ controllers.
Edit:
S1+) Okay, so to add text to the world map (flight), you'd need to:
1) Find space in memory for a font to show text
2) Find a rendering layer that the text could be put on (or letterbox the bottom of the screen like Trials of Mana to switch rendering modes at the bottom of the screen to give access to a needed rendering layer)
3) Create some sort of coordinate system for retrieving place names
4) Populate a table based on that coordinate system with place names
5) Create place names for places not already named somewhere in game data
6) Find somewhere in code where it would be appropriate to do the place name lookup
7) Use the place name to build a tilemap in RAM
8) Find where in code it would be appropriate to update the tilemap in VRAM
9) Find where in code to handle mode switching if necessary
And that's off the top of my head; it would likely be worse than that.
The first issue, space for a font, could easily be a show stopper as I'm not sure how much if any is available. Then finding somewhere (not like, aesthetically, on screen, but literally, in hardware-defined image rendering placement) to put the text may not be realistic depending on what's already in use for showing the horizon, compass, ground and Flammie. Populating the data for locations could take a huge amount of time depending on how thorough you want to be; but even if you kept things minimal it would be no brief chore.
I also looked into some of the Northtown issues you brought up. I was able to reproduce the garbage graphics data on right screen edge indoors issue, but no clue what's causing that; I may poke at it some but there's a distinct chance it's not realistically fixable. My first two experiments with the Magic Rope in the Northtown Ruins issue were a bust (changing aspects of the doors in the hopes of changing when the rope point is set); I have another idea regarding "fixing" it, but it's a little more involved so will need to set some time aside to play with it but I'm pretty sure I have a solution.