OK, so I have good news, and good news. Which do you guys want first?
The good news is, after looking into this more I realized it should actually be pretty easy, so I'm going to make it. And it should be able to work directly with the ISO, so no need to also extract/import the dol. Easy peasy.
The other good news is that I think I can write a parser to read mods in this form (the mods in the OP are all pretty consistently written like this):
Fountain of Dreams - Remove Side Platforms
-Remove (Disable) Side Platforms
-Disable Water Jets
[Zauron]
Version ── DOL Offset ────── Hex to Replace ────────── ASM Code
1.00 ────── 0x1C84C4 ──── 801B0014 -> 4800013C ──── (lwz r0,20(r27) -> b 0x13C)
─────────── 0x1C84BC ──── EC0007FA -> FC000028 ──── (fmadds f0,f0,f31,f0 -> fsub f0,f0,f0)
1.01 ────── 0x1CDABC ──── 801B0014 -> 4800013C ──── (lwz r0,20(r27) -> b 0x13C)
─────────── 0x1C8E20 ──── EC0007FA -> FC000028 ──── (fmadds f0,f0,f31,f0 -> fsub f0,f0,f0)
1.02 ────── 0x1C9494 ──── 801B0014 -> 4800013C ──── (lwz r0,20(r27) -> b 0x13C)
─────────── 0x1C948C ──── EC0007FA -> FC000028 ──── (fmadds f0,f0,f31,f0 -> fsub f0,f0,f0)
PAL ─────── 0x1CB0B8 ──── 801B0014 -> 4800013C ──── (lwz r0,20(r27) -> b 0x13C)
─────────── 0x1CB0B0 ──── EC0007FA -> FC000028 ──── (fmadds f0,f0,f31,f0 -> fsub f0,f0,f0)
So the program can read from a text file "library" of all the mods. As new mods come out, they can easily be copy-paste incorporated into the library (we could keep the latest copy of this library in an OP somewhere, so even that wouldn't be left to user error). For the game settings, I'll just manually code those in. And for longer paste-overwrites we could probably use a modified version of the most common format that people have been posting them in.
And since I amazingly have drag-and-drop functionality working in Python 2.7, the whole program usage would be like this:
Open program,
Drag ISO onto program,
Click check-boxes for the mods you want,
Hit Save.
A process so simple it could almost be a haiku.
Yes, 32/16/8-bit overwrites would be super easy. But you cannot cut corners with ASM injection codes. I can’t stress enough that there is no one-size-fits-all way to do them.
ASM injection codes can be placed anywhere you want in the DOL. It needs the following parameters:
1) The DOL offset for the equivalent RAM line where you code inject “starts”. Basically, what function you are tapping into.
a. See below for the “RAM offset to DOL offset” idea. This would be nice because you always make codes in the RAM first. And then have to find DOL offets.
2) The location of where to place your custom code in the DOL. You need to know the RAM address for this as well.
Then what it should automatically do:
3) Add the instruction for a branch from injection to the start of custom code.
4) Then give you the option to include a branch back at the end of your custom code to the injection line +0x4. But this would ideally be optional because you could have your code branch to some other function and have it resume there, instead of specifically going back to (injection line + 0x4).
*all these branches are relative to RAM offsets,
When you tell people specific DOL offsets for an ASM inject code, you’re basically forcing structure into their DOL (project?) that you know nothing about and that “hopefully” lines up efficiently with codes that everyone has written and will write in the future. This practice kind of makes me cringe.
Other thoughts:
- There needs to be a “backup” function of some sort, or, just having it point to a DOL file instead of the whole ISO. If you messed up a placement offset in one of your lines in the text file that causes your game to crash, do you just plan on leaving it up to the user to be able to view the RAM or have access to a RAM dump and go to that accidental offset, find the original hex line and then copy that over to their messed up DOL to “fix” the problem.
o With your current thought for the program, would there still be functionality for dragging a DOL itself into the program for editing or would you have to have an ISO and the whole nine yards in order to use it?
o I personally think it would be best to have it be able to work with both and then if you have a lone DOL open, there can be a button for “Import into ISO”, where you can just select a target ISO and it immediately does the overwrite.
- A Gecko code to DOL mod function (really just a RAM offset to DOL offset finder). Have a trimmed vanilla RAM dump built into the program, copy the gecko code RAM offset value + some adjacent lines and then switch back to the same offset in the DOL and search upwards for a match.
- What about just a general DOL Manager? Ex. A tab for “Character Move Modifications” where you can add/change interrupts to special moves. Changing the default names of characters….just **** like that. Like built-in little mini functions that involve the DOL. Frame speed mods? Because those are DOL changes.
Lol. Actually, if you just made a Gecko code (overwrites and injections) to RAM program, then we almost wouldn’t even need this thread anymore…
I also would not worry about coding a parser to find DOL mods. Just spend that time manually making a text file with the current ones and giving people instructions on how to add more to the text file. You know that future DOL mod posts are not going to always be in some special format anyway and that the majority of people will just add them in as text anyhow.
- A "new DOL mod" function that uses the main program window to enter info and have it automatically save to your text file.
I’m just trying to look at the program from a larger perspective. Having only the simple functionality you listed above would still be helpful for people. Sorry this post is cluttered. I was just typing anything that came to mind. I basically live in the DOL, so I've got a lot to say about it.