Official Melee Code Manager (v4.4.1) - Easily Add Mods to Your Game!

[DRGN]

Update in the works.

Achilles1515 Soo, about those commands....

Those commands seem equivalent to me in the converter. Both "lwz r0,0(sp)" and "lwz r0,0(r1)" convert to "80010000". And both "lwz r0,0(rtoc)" and "lwz r0,0(r2)" convert to "80020000". Do you mean going from hex to ASM, i.e. you want "80010000" to convert to "lwz r0,0(sp)" rather than "lwz r0,0(r1)"?

How would I add codes for Kirby's throws? I know the hex addresses in the Start.dol, but I don't know what I should be changing them to.

I wanted to change two things:
1) make f/b throw uninterruptible, as they are in SD Remix. The mash timer is at 0xDADC0 in v1.00, and 0xDB20C in v1.02. I tried changing EC 01 00 28 (the timer) to 60 00 00 00 (to nop the timer), but instead of being inescapable the two throws just never grab the other character in the first place.

2) let Kirby have his jumps after u/f/b throw. The address is 0x79FB0 in v1.00, and 0x7A24C in v1.02. I again tried changing 98 7E 19 68 (the jump delete thing) to 60 00 00 00 (to nop the deleted jumps), and again I got some weird behavior. Kirby reacts to jumping out of the throw now, but it's not really a jump. Kirby goes through the jump animation, then keeps floating upwards instead of coming back down. He floats to the blast zone and crashes the game.

What should I be changing the code to? The nop function clearly isn't working.

All of my testing was done in v1.02. I had found the addresses for v1.00 and did a search in the v1.02 Start.dol to find the addresses there.



EDIT: So upon further research of the inescapable throws, I have found that EC 01 00 28 translates to

fsubs f0,f1,f0

in PPC code. In other words, the value of f0 (I'm assuming the escape trigger) is subtracted from f1 (I'm assuming the mash logging thing) and then stored back into f0.

So I tried changing that to an fadds function, but that only made the timing different(?) for the escape. I THINK the mash/escape threshold is >0, so f1 would be incremented with every mash input to the point where f1 - f0 >= threshold (which would read f0), which is why that didn't work. I think.

I also looked at SD Remix's Start.dol (Kirby throws are inescapable in SDR), and they just nop'd (EC010028 -> 60000000) the timer (EC010028 -> 60000000) and it works perfectly, which makes me wonder if there's some bug that they fixed to make the timer just disappear. They did nop a lot more in the .dol than I have, and almost everything is 0'd until offset 0x2700 or something.

Still very confused, any help is appreciated.

What if you change the f0 argument for the timer to 0, so that nothing is subtracted from f1? Maybe you can post in the SD Remix thread and find out who made the code for the throws.

 

[Kekker]

What if you change the f0 argument for the timer to 0, so that nothing is subtracted from f1? Maybe you can post in the SD Remix thread and find out who made the code for the throws.

I actually didn't think of that, I'll try when I get the chance and post here with results.

I've already posted this question in the SDR thread, I have yet to get a response.

EDIT: Ok I think I fixed it.
I tried what you said, changing the f0 to just 0, but that just made the code recognize the float named 0, not the number 0. So it didn't do anything.

BUT, I had also been looking at the NEXT 4 bits of code, which are as follows:

stfs f0,6732(r31)

So the full 8 bits of throw code are

fsubs f0,f1,f0
stfs f0,6732(r31)

In English, subtract the float f0 from float f1, store back in f0, and then store the float value stored in f0 into register r31. I am now thinking that the float values are the mash timer increments, and the register is what actually checks for a grab release.

I changed the f0 in the SECOND command (stfs f0,6732(r31)) to f1, and now the lvl 9 CPUs cannot escape Kirby's throws, whereas before they would escape 9/10 times. I have yet to test this against a human opponent, but I am pretty sure I fixed it.

So, for anyone else who wants to try this, these are the hex addresses I changed:

Offset 0xDB210 (RAM address for you Debug Dolphin users: 800DE630)
D0 1F 1A 4C -> D0 3F 1A 4C

and what the PPC code will look like:

fsubs f0,f1,f0
stfs f1,6732(r31)

EDIT 2
Ok, I didn't fix it with that, but I'm on to something. The BACK throw was, as far as I can tell, inescapable, but the FORWARD throw was escapable. That said, the CPUs could only escape the fthrow towards the end of the animation; since forward throw is a longer animation than back throw, I am fairly certain that I did in fact succeed at nullifying the timer, and the float stored in f1 is now a constant instead of a changing number.

However, I ALSO think that the float is now a set time, instead of a decrementing/incrementing timer. Which would make sense in this context if the time is a few frames after back throw is already over. Back throw would never get to this time, but forward throw would due to the longer animation.

So, with this in mind, I went to the code again and changed the fsubs to fadds, like I did before, but instead of adding f0 to f1, I added f1 to f1, doubling the timer, and then stored that into f1, like so:

fadds f1,f1,f1

I did not touch the other code I changed, so the PPC code now looks like this:

fadds f1,f1,f1
stfs f1,6732(r31)

I have been playing lvl 9 CPUs for the last ~40 minutes using nothing but f-throw and b-throw, and the CPU has not escaped as of yet.

The new code:

Offset 0xDB20C (RAM address for you Debug Dolphin users: 800DE62C)
EC 01 00 28 -> EC 21 08 2A
Offset 0xDB210 (RAM: 800DE630)
D0 1F 1A 4C -> D0 3F 1A 4C

and what the PPC code will look like:

fadds f1,f1,f1
stfs f1,6732(r31)

Sorry for the long post. I hope this worked, I hope it makes sense. Hopefully it'll be be useful to others in the future.

EDIT 3: formatting.

 

[DRGN]

Update! Plus a 32-bit build!​

Punkline helped me identify some bugs relating to standalone functions and the custom branch syntaxes, so this should handle those and give you guys some powerful functionality. When Punkline posts some of the things he's been working on, you can start to get some ideas of how you can use these to reduce your game's custom code length, and make things a little more modular and simpler to modify.

And I haven't forgotten about your guys' other feedback so far. This is just a small update. I have plans for another larger one when I can get to it, encompassing your guys' suggestions and more.

Changelist (from v2.0):

- 32-bit build now available!
- Fixed a parsing bug that would occur with mods that use several standalone functions
- Fixed ASM compiling bug relating to using standalone functions with custom branch syntaxes
- Added measures to prevent enabled/disabled mods with the same injection points from conflicting
- Scrollwheel support!
- Added 'CTRL-A' (Select All) support for text entry fields
- Slightly improved ASM > Hex conversion efficiency
- Number Conversion Tool: 'L' character removed from negative 32-bit floats
- Font size now adapts to user's system's font size setting (tested on Win7 & 8.1)
- Increasing/decreasing font size is now an option in the settings file​

As always, downloads in the OP (in the 'Important stuff' spoiler).

 

[flieskiller]

^ Cool! Right the moment I need that software, it gets updated less than a hour ago, sweet timing.

 

[Doq]

*puts in MTB3*

 

[flieskiller]

Using the "Add New Mod to Library" button, how do I connect a table (raw injection) with a code I want to add? Some codes have a table that it refers to, but I see no way to make a table put in a specific place. Should I just inject it at the right place in the DOL myself and the program do not overwrite it or there is another solution?

edit: found it it's just a static overwrite with all the Hexes together looking at the Extended Name Entry code

 

[DRGN]

Using the "Add New Mod to Library" button, how do I connect a table (raw injection) with a code I want to add? Some codes have a table that it refers to, but I see no way to make a table put in a specific place. Should I just inject it at the right place in the DOL myself and the program do not overwrite it or there is another solution?

You can use a standalone function. There's a little more description in the second post, but basically they are blocks of code that can be used by any number of mods, but are only written into the game once. You can then access them by name. For example, say you have a simple mod with just a single injection and one standalone function:

Example Mod
This is an example description for an example mod. (optional)
[DRGN]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code (<- optional line, but helps with readability)
1.02 ------ 0x1234 ---- 8001001C -> Branch

01234567 01234567
bl <exampleFunction>
01234567 00000000

<exampleFunction>
01234567 01234567
01234567 01234567
01234567 01234567
01234567 01234567

So 'exampleFunction' could be your table. The program will find the next available free space where it will add the code. Other mods can then jump to it too by using some type of branch (doesn't have to be just bl) followed by the function name in angle brackets. Execution will automatically go back to your normal injection after it's done with the standalone function.

Alternatively, you could put the table into the game manually if you want it at an exact location. The other special branch syntax can branch to a specific RAM address such as the game's native functions, or whatever else that you know will always be in the same place; the syntax would be, for example, "bl 0x80012345" (you can use the converter on the tools tab to get a RAM address from a DOL offset). Just make sure you're not using space that the program identifies as free space, or your code may be overwritten. However, you can modify what the program will use. Open up the settings.py file in a text editor for notes and customization options for this.

 

[Kekker]

- Scrollwheel support!​

Today is a good day.

 

[flieskiller]

I have a bug that some codes are highlighted in green, but I didn't add them at all. I could toggle them, but on "Rescan for Mods", they just reappear green again.

Also, I have a request: Hiding codes in the list. I removed a lot of codes of the documents and added my own so I don't have to scroll and find mines, because I'm doing a competitive build and it would be neat to be able to hide unwanted codes, like character modifications.

 

[DRGN]

I have a bug that some codes are highlighted in green, but I didn't add them at all. I could toggle them, but on "Rescan for Mods", they just reappear green again.

Also, I have a request: Hiding codes in the list. I removed a lot of codes of the documents and added my own so I don't have to scroll and find mines, because I'm doing a competitive build and it would be neat to be able to hide unwanted codes, like character modifications.

This may happen if you have several similar mods that use the same offsets or injection points. You can just remove the variations you don't intend to use from the library. I may be able to add some more methods to prevent this in the future though. Which mods are they?

 

[flieskiller]

It's the "Boot to Character Select Screen", I don't use any code of that matter and it's green. in-game, it boots normally without booting to the CSS.

 

[flieskiller]

also, there is a place in the beginning that gets writen a bunch of 0, so you might want to replace ( 0x15CC, 0x1698 ) with ( 0x15F0, 0x1698 ) so a code won't go into void and crash

 

[IcytheLucario]

I wanted to do animation/attacks modifiers for Bowser/Giga Bowser for a code, but I got confused on the offset that their on.

Like what is the offsets or anything that is part of Bowser and his animations and attacks and what is the same with Giga Bowser?

Yeah, I'm a beginner here so I'm learning to use this stuff.

 

[flieskiller]

^ This software is to modify the Start.dol. What you want to modify is in the file of Bowser itself, so this here won't help you to achieve your goal. I didn't work with character modifications at all, so I can't send you somewhere, you'll have to search.

 

[Achilles1515]

DRGN,

One suggestion I've had for awhile but never said anything about:

What do you think about moving the "Overwrite Debug Menu" option down towards the bottom of the window?

While using MCM, there have been times where I go to click the "Save Changes" button but mis-click slightly below it. Instinctively, what is the first thing you do when you mis-click really close to your aim? - You click again in the correct place immediately afterward (like a slow double-click). The problem here is that once you've done that, you checked the "Overwrite Debug Menu" button on accident, initiaited the new code placement and destroyed all non-MCM data that was placed in the Debug Menu area, AND saved the file.

Idk if anyone else has done this, but it has happened to me a few times. Placing it at the bottom will obviously make it harder to activate by accident.

 

[DRGN]

also, there is a place in the beginning that gets writen a bunch of 0, so you might want to replace ( 0x15CC, 0x1698 ) with ( 0x15F0, 0x1698 ) so a code won't go into void and crash

Will do! Thanks.

I wanted to do animation/attacks modifiers for Bowser/Giga Bowser for a code, but I got confused on the offset that their on.

Like what is the offsets or anything that is part of Bowser and his animations and attacks and what is the same with Giga Bowser?

Yeah, I'm a beginner here so I'm learning to use this stuff.

You might want to try playing with the program Crazy Hand (found in the Movesets subforum).

DRGN,

One suggestion I've had for awhile but never said anything about:

View attachment 105575

What do you think about moving the "Overwrite Debug Menu" option down towards the bottom of the window?

While using MCM, there have been times where I go to click the "Save Changes" button but mis-click slightly below it. Instinctively, what is the first thing you do when you mis-click really close to your aim? - You click again in the correct place immediately afterward (like a slow double-click). The problem here is that once you've done that, you checked the "Overwrite Debug Menu" button on accident, initiaited the new code placement and destroyed all non-MCM data that was placed in the Debug Menu area, AND saved the file.

Idk if anyone else has done this, but it has happened to me a few times. Placing it at the bottom will obviously make it harder to activate by accident.

Makes sense. Sure, I'll do that.

 

[DRGN]

Working on updating this. Large redesign in a couple areas. Mostly mod organization (so things can be easily organized as the user sees fit) and allowing amending/editing of codes within the program, so hopefully you don't need to go into the Mod Library text files themselves as much.


Feel free to brainstorm ideas that could be included.

 

[Achilles1515]

So awhile back, I made a memory card exploit containing the codes for the Super Nebs 4 build.

I made this rather easily using MCM.

I've stated before that ( 0x18DCC0, 0x197B2C ) in the DOL is used for Tournament Mode code. If you do not plan on using Tournament Mode, then this is now a good amount free space. Let's use it.

---------------------
DATA A
1) Set MCM to use the above mentioned code region in the settings.py file.
2) Add and apply injection codes you want on the exploit to any DOL. This is just a dummy DOL file that is not used for anything else after these next couple steps. I would zero out the entire area being written to in the DOL before this step so you clearly know where the end of the added MCM codes is (they get applied immediately after one another).
3) Open the modified DOL in a hex editor and go to the start of the tournament mode section where you wrote new codes to (0x18DCC0).
4) Copy the entire chunk of new code data that was added. Let's call this "Data A".

---------------------
TABLE B
Now we need to make "Table B", which is simply a table of 32-bit overwrites.

Each entry in Table B is 8 bytes in size. First four bytes is the RAM address. Second four bytes is the overwrite value. Easy. Make a table of successive entries. The table ends when the RAM address offset is specified as 0x00000000.

In regards to the injection codes we applied to the dummy DOL earlier, we have the actual code data to bring to the mem card exploit (Data A), but we still need the 32-bit overwrites that branch at the injection point to the code that MCM applied to the tourney mode section.

You can find the branch value within MCM by clicking on the "Details" of an injected code.



So the table entry for the above code would be:
802FCCE8 4BE95AB8
(remember, 802FCCE8 is the RAM equivalent of 0x2F98C8 that is in the picture above)

Any other 32-bit overwrite codes, the "04" codetype, can be added to Table B as well. Things like "C-Stick in 1P Mode".

Example Table:

Super Nebs Overwrite Table
- first part is 32-bit overwrite codes, "04" codes.
- second part is 32-bit overwrite branches to tourney code area for MCM added injection codes.

8016B480    60000000
801D1548    60000000
8015d94c    4e800020
8015d984    4e800020
801A218C    60000000
803EA6C8    53757065
803EA6CC    72204E65
803EA6D0    62756c6f
803EA6D4    75732034
803EA6D8    00000000
8022d640    60000000
801A1C58    38000000
8022D1E4    48000154
8022CF04    480001e0
8025A3BC    4bf36d24
802fcce8    4be94524
8026304C    4bf2e24c
801a1e34    4bfef55c
801A4B70    4bfec918
80263058    4bf2e44c
801C0A48    4bfd0bdc
00000000

--------------------
Data C
This is the master, hard-coded ASM data in the memory card save. MCM is not used for this. Data C is an ASM function that runs when the exploit is triggered. This function does the following:

1) Parses through Table B and writes the overwrite value to the associated RAM address. Repeat until it sees a null.
2) Writes Data A (all the injected code data), to RAM offset 0x801910E0 (which is the RAM equivalent of 0x18DCC0 in the DOL).
3) Any other necessary ASM to make the exploit work.

Once this happens...you're done and all your codes are applied with the exploit. Generally speaking, Data C could be a finite length and code that doesn't really change from exploit to exploit.

It would be radical if MCM could automatically printout Table B based on the current static overwrites applied and the injected code branch overwrites. In fact, Table B (including the null) with Data A appended to it, would be the best printout (Master ASM in Data C will know that the code data immediately follows the null table entry).

Copy this printout, open up your Dolphin uncompressed save state [*holding Data C and everything else needed to execute the memory card exploit in the memory card location] in a hex editor, paste printout at memory card location after Data C, save & close. Open Dolphin, load modified save state, save game, and now you have your memory card exploit as a .gci.

* this ready-to-go file would be available for download.​

Custom mem card exploits in a jiffy. Let me know if anything doesn't make sense.

 

[DRGN]

Ohh. Nice!

If the rest of the save file is standard, then what about having the output be a combination of everything, including Data C (perhaps just creating the whole .gci file)? If one has other things saved in their game, like nametags or vs. data that they want to keep, they could still generate this gci file, and then copy the necessary code portion to their own save.

 

[DRGN]

I noticed that it looks like branches with the link register and/or AA bit set (bl/ba/bla) do not disassemble correctly. For example, 48000005 disassembles to bl 0x0005 instead of bl 0x0004, and then therfore throws an error when you try to reassemble it (on the branch distance not being a multiple of 4).

(I also know about and have fixed the issue where code that's not aligned to 8 bytes in the last section doesn't compile correctly, btw, which will be included in the next update.)

I figured this branching issue was an issue with the compiler binaries (powerpc-eabi-as.exe, ...ld.exe, ...objcopy.exe, and vdappc.exe), since PyiiASMH (the module that handles ASM to-from Hex conversion) is fairly simple, and mostly just acts as a mediator to the compilers. So I looked all over for others who might have had issues with them, and tried to research more about them. Long story short, I didn't find much, so I finally looked back into PyiiASM, and surprisingly found what seems to be the problem there. Odd thing is, it has a comment that says "Branch instruction fixes", which makes it seem like this behavior is intentional. Does that make sense to anyone?

Also, I wanted to know, has anyone found any issues with other commands?

Achilles1515 , Punkline , SinsOfApathy

If any of you know of others who might have something to add on this stuff, you could tag them as well.

Also, Achilles, there's still this question on the (sp) & (rtoc) commands (bottom of the post). I think I understand what you're asking, but I just wanted to confirm.


Edit: One more question.

It was suggested here to use powerpc-gekko-as, powerpc-gekko-ld, and powerpc-gekko-objcopy, rather than powerpc-eabi-as, powerpc-eabi-ld, and powerpc-eabi-objcopy. Does anyone know the difference with these? I'm guessing the latter might include assembly/disassembly functionality for gekko as well as the "standard" instruction set that GC & Wii use (whatever that might be). But of course I'm not sure because I haven't found any documentation or explanation of these. Thanks for any info you might have.

 

[SinsOfApathy]

Gekko is the name of the PowerPC processor line that the GC used. It has nothing to do with the Gecko device itself.

My AsmWiiRd uses the Gekko version of the toolchain, and the EABI ones are available in the devkitPro tools. They're byte for byte identical, just with different naming. I also renamed the files for the sake of argument and decompiled a C2 code made up of only "48000005" and it produced the exact same output of "bl 0x04" with both EABI and Gekko versions (because they're the same thing.)

I don't use MCM, and probably never will to be honest, so I cannot offer anything more than that.

 

[DRGN]

Gekko is the name of the PowerPC processor line that the GC used. It has nothing to do with the Gecko device itself.

My AsmWiiRd uses the Gekko version of the toolchain, and the EABI ones are available in the devkitPro tools. They're byte for byte identical, just with different naming. I also renamed the files for the sake of argument and decompiled a C2 code made up of only "48000005" and it produced the exact same output of "bl 0x04" with both EABI and Gekko versions (because they're the same thing.)

I don't use MCM, and probably never will to be honest, so I cannot offer anything more than that.

Oh, right, I didn't mean to refer to the Gecko [or any other hardware] device (I accidentally spelled it gecko). I meant to refer to the WiiRD/Gecko codeset, which extends the Gekko instruction set, correct? What I mean is, there are instructions you can use in WiiRD/Gecko that are not native to the Gekko processor's codeset. I haven't researched this, but I figure these "new" commands must just be a simple combination of commands existing in the Gekko processor's codeset, which are converted or in a sense decompiled/deassembled at runtime by the Gecko codehandler.

So, my guess was that the compiler with "gekko" in the name was meant to handle these extra/new Gecko codes, while the other did not, which as you've informed me is incorrect since they're identical. That certainly answers my question of which I should use. Thanks!

Do you use .gct files for your hacks rather than dol mods?

I'm currently working on functionality for MCM to allow working with mods in the form of ASM within the program. So during editing or creation, one doesn't even need to go through the step of converting the code to hex. All you would need to do is hit save and the code is filtered (for comments and such), assembled to hex, injected into the DOL with updated branches, and saved to the ISO. Conversion would still be preferred when people share the mods though.

Anyway, as for this matter, I certainly don't understand these branch "fixes" introduced by PyiiASMH, but I'm going to remove them as I see no use or purpose in them here. I can't even really imagine a scenario where these fixes would be correct or useful, so it just seems very strange to me. (MCM actually creates its own branches for injection mods, but branches contained within the codes are still compiled/decompiled by PyiiASMH, which is why this was an issue.)

 

[SinsOfApathy]

Gecko codes aren't an extension of the instruction set. The gecko codehandler is written to just parse out the upper 8 bytes as an opcode, then do assembly based on logic assigned to that opcode.

Do you use .gct files for your hacks rather than dol mods?

No, I have custom codehandler stubs that I inject with a tool I wrote for Dolphin, or I replace Dolphin's gecko codehandler. Otherwise, I keep them piecemeal enough in Gecko codes until I get what I need before putting them together.

 

[Misa]

Awesome work, I'll be looking forward to playing around with this.

 

[Deleted member]

Do you like awesome custom codes? Do you like Melee? Do you like awesome custom codes IN your Melee? Then this is the program for you!​

This is the best way to view, add, and/or remove all of your code based mods in Melee, and set up your game’s default gameplay settings (so they all finally stay remembered!). Supports DOL mods (including injection mods) as well as some Gecko codes. Everything is done in a very easy-to-use interface, which simply presents you with a list of available codes, and allows you to install or uninstall them from your game with just a single click.

Cool stuff for average users:

• Easiest and fastest way to add mods to your game. Period.
• No need to understand hex editing or ASM coding.
• Easily adjust your game’s default settings (stock mode, items/stages, etc.)
• Provides a visual ‘fill-meter’ to show how much space is left for custom code.
• You don’t even need to extract/import the DOL from your game to update it.
• Eliminates the old problem of mods' custom code overlapping one another.
• Automatic, efficient usage of available ‘free space’ for custom code.
• Offers a simpler way to share new codes (with only one simple copy/paste).
• The post below this doubles as a centralized, publicly editable resource for all mods.

Cool stuff for developers:

• Create injection mods without needing to calculate branches.
• Use RAM addresses for DOL mods instead of searching for DOL offsets.
• Easily convert Gecko codes to DOL mods using the above functionality.
• Introduces a new branching syntax for easily making function calls. (info below)
• ASM to Hex converter built-in.
• Automatically looks up the ‘original’ code when adding a new mod via the GUI.
• Troubleshoot problems easier by quickly swapping out potential conflicting code.
• Relocates custom code after it has been edited if it uses more/less space.
• Large game projects could potentially be much more modular and manageable.
• Plus more useful stuff in the all-new Tools tab!

Take a look!

View attachment 71645

Dark green are mods that are currently installed, while light green are mods selected to be installed once you hit ‘Save’, and those in red are mods that will be uninstalled upon saving.

You can give this program a DOL file, or an entire ISO.

The ASM of injection mods is automatically aligned directly after one-another to optimize the DOL’s free space. If updates or changes are made to the mods, the locations in the DOL of their custom code will be adjusted accordingly the next time you save. (If you make changes to any mods while the program is still open, you don't need to close and re-open the program to load the new changes, you can just click the ‘Scan for Mods’ button to update the codes in the program before hitting save.)

View attachment 71646

View attachment 71647

Yeah, I have a download link, I'm gettin' to that, but if this is your first time using this, please read the important stuff below first.

Spoiler: ’Important stuff!’

This will typically work best if you start using it to work with a fresh, unmodified DOL or ISO. If you already have codes installed in your game, that’s OK, it will automatically detect those too as long as they’re included in the “Mods Library”, which is the folder of text files that contains all of the mods. There are already a ton of mods included by default (I've added a lot more since the original release of this). And it will continue to grow. If the mods you want are actually still not in there, it is but a simple matter to add them. You can simply copy/paste the mod from here on the boards (if it's in the standard format) into any of the text files in the "Mods Library" folder. Or, if it’s a Gecko code you want to convert, it’s not in the expected format already, or if you want to create a brand new mod, you can use the GUI to add it (pictured above). Check out the spoilers in the post below this one for more info. And feel free to post if you need help.

Codes in your game that are not added to the library may be overwritten when you use this program to modify your ISO. There are actually two solutions to this: 1) Add the code to the library as mentioned above, or 2) edit the “settings.py” file to ignore the DOL sections where those other, non-library codes reside (there are notes in that file that go into more depth on this). However, because of these risks, I recommend backing up your game just in case, or more specifically, your DOL file (the file that holds these codes), before giving this program a shot. There's a clearly visible button labeled "Export DOL", which you can use to easily do this. Also, if you need one, the download comes with copies of the original DOLs for each game version.

Note that because of issues mentioned above, this currently wont work for 20XX. I have 20XX, which is awesome, but I also like to play my own customized Melee, which is a bit different. So this allows me to modify that however I want, or even build it from scratch if needed, in just a couple minutes. However if you guys like the direction a program like this could take Melee, then I could probably work with @ Achilles1515 at some point for 20XX compatibility. Honestly, a program like this has the potential to handle something like that and much more, in terms of mod packs and simplified, personalized customization.

The Gecko Codes tab is still experimental tech at this point. It's based on work by Dan Salvato to internalize the Gecko Codehandler into the DOL. However we've had some issues with it, and as such not all Gecko codes will work (typically 02 & 04 type codes seem to work, but C2 codes fail). Luckily, with this program it's now much easier to convert Gecko codes to DOL mods (there's a short guide for how to do this in the "Converting Gecko Codes" spoiler in the second post). And I've already converted a lot of Gecko codes to DOL mods anyway. But I decided to leave this in because even if it's limited, it's still some additional functionality. Plus, someone else out there might decide to look into it and find the problem or some patterns. If you're interested, you can find the original thread and the current debugging conversation on this here.

Important note on making changes to mods: If you ever need to change the injection point that a mod uses, or a location of a static overwrite, then you must first uninstall the mod from your game, save the changes to the game, and only then make such changes to the mod. Then you may reinstall/re-enable the mod. This is necessary to ensure that no changes that are no longer used from the old version of the mod are permanently made in your game. Naturally, this is because if you change the places that a mod targets, the program has no reason to look at or modify code from the old areas. Changes to ASM functions themselves do not require this. It might sound weird, but it will quickly make sense if you're familiar with this stuff. The benefit of all of this is that it has the potential to make large, complex game projects much more modular and manageable (for both the developers and the users).

Custom debug menus can be used, but being able to use them to control other mods will depend on the method you’re using. Control that does not target the mod itself, such as setting a flag that the mod will independently use on its own, or working by only modifying the game’s code (e.g. to toggle an injection mod’s branch back to the game’s original code, as long as you save/restore the branch) will work as normal. However, targeting the mod’s custom code with a normal branch will not work because its location is variable. Instead, you can target them as you would a standalone function. Check out the second post in ’Standalone Functions and Special Branch Syntaxes’ for details.

Ok, now you can have it.

Download - v2.1 (64-bit)

Download - v2.1 (32-bit)​

If you feel the urge to give back:
Or you can follow me on Patreon.

Spoiler: Changelog

Changelist from v2.0:

- 32-bit build now available!
- Fixed a parsing bug that would occur with mods that use several standalone functions
- Fixed ASM compiling bug relating to using standalone functions with custom branch syntaxes
- Added measures to prevent enabled/disabled mods with the same injection points from conflicting
- Scrollwheel support!
- Added 'CTRL-A' (Select All) support for text entry fields
- Slightly improved ASM > Hex conversion efficiency
- Number Conversion Tool: 'L' character removed from negative 32-bit floats
- Font size now adapts to user's system's font size setting (tested on Win7)
- Increasing/decreasing font size is now an option in the settings file​

Changelist from the original release of this program:

- Added support for standalone functions (can be shared by multiple mods)
- New convenient calling/branching syntax for functions (e.g. "bl 0x800948a8")
- The 'Offset' value can now optionally be given as a RAM address instead
- Program renamed, from "DRGN's DOL Manager" to "Melee Code Manager"
- Can now add/remove & manage Gecko codes in the DOL (thx to R&D by Dan Salvato)
- Added the Tools tab with the following tools -

-- Interface to easily add new codes to the library (formats them for you)
-- Can add new codes in the form of assembly without needing to convert first
-- ASM <-> Hex Converter (available separately from the above functionality)
-- Number converter, RAM address converter, and code offset converter
-- Text to Hex (ASCII) converter​

- Drag-and-drop now works with the program icon (previously only available on GUI)
- Before overwriting/changing a game's DOL, now asks if you'd like to back it up
- Now uses '#' rather than '*' for comments in Mods Library (the code text files)
- Fixed an alignment problem occuring with free space in non-v1.02 game versions
- Better error handling in case of a problem while applying a mod to a game
- Better parsing of mods library (attempts to explain errors if encountered)
- New, more convenient syntax for long static overwrites (and can be any length)
- Recognizes .GCM files now rather than .GCN
- Fixed the audio causing a crash when no audio drivers were detected
- Increased custom code free space by 0xF64 (thx to R&D by achilles)
- Free space regions exposed to user via settings file (can set to ignore regions)
- Injection Mods show how much space they use (by byte; separate from the meter)
- Reorganized the mods in the text files by their purpose
- Converted a lot of Gecko codes to DOL mods and added them to the library​

In the future, I don't see why a program couldn't use packs (even could be a standard zip) which include any combination of game files, textures, audio, and/or ASM. For example, the 'Debug Menu Replaces Tournament Mode' combined with the graphics for it, or a mod pack for a stage, where you might need the stage file as well as a few code changes separate from it, and perhaps music. There could be a program that could install all parts of it, as one unit, directly to your ISO in one step. Adding a custom debug menu builder to this would also likely be possible.

- - -​

Shoutouts and thanks to @shuall, @_glook, @ Achilles1515 , @Jorgasms, @ SinsOfApathy , and others, who have each stopped their busy hacking to answer questions or give suggestions. Feel free to PM me if you'd like the pretty 3.6K+ lines of source code.

I'm almost certain that I skipped over something, but there doesn't appear to be an option for adding our own codes (as far as I've seen). This is a problem because I use a lot of custom made codes and there is (obviously) no option for them.

I appreciate an easy-to-use code manager system, but I think this is too easy. Everything you're ever going to use is already laid out in front of you to the exclusion of everything else.

I'd prefer if you simply made a Melee equivalent to Brawl's .gct editor, which can be found here

 

[Achilles1515]

Also, Achilles, there's still this question on the (sp) & (rtoc) commands (bottom of the post). I think I understand what you're asking, but I just wanted to confirm.

Sorry I never responded to this. I think my question is irrelevant now. I REALLY thought there was a time I input ASM using "sp" and "rtoc", as in the picture below, and your program threw an error of some sort. But I can't reproduce it and it seems to work great.

I'm almost certain that I skipped over something, but there doesn't appear to be an option for adding our own codes (as far as I've seen). This is a problem because I use a lot of custom made codes and there is (obviously) no option for them.

I appreciate an easy-to-use code manager system, but I think this is too easy. Everything you're ever going to use is already laid out in front of you to the exclusion of everything else.

I'd prefer if you simply made a Melee equivalent to Brawl's .gct editor, which can be found here

This program is so much more advanced than a GCT editor. Not to mention you have to rely on a Gecko codehandler when using GCTs and the default Gecko codehandlers, for nearly all GameCube setups, have a GCT length limit that is quite small.

 

[DRGN]

Sorry I never responded to this. I think my question is irrelevant now. I REALLY thought there was a time I input ASM using "sp" and "rtoc", as in the picture below, and your program threw an error of some sort. But I can't reproduce it and it seems to work great.

View attachment 114098


View attachment 114102

This program is so much more advanced than a GCT editor. Not to mention you have to rely on a Gecko codehandler when using GCTs and the default Gecko codehandlers, for nearly all GameCube setups, have a GCT length limit that is quite small.

Were you maybe thinking about disassembling 80010000/80020000? They translate to "lwz r0,0(r1)" and "lwz r0,0(r2)"rather, than "lwz r0,0(sp)" and "lwz r0,0(rtoc)", respectively. I can change that to the latter though if it's preferred.

I'm almost certain that I skipped over something, but there doesn't appear to be an option for adding our own codes (as far as I've seen). This is a problem because I use a lot of custom made codes and there is (obviously) no option for them.

I appreciate an easy-to-use code manager system, but I think this is too easy. Everything you're ever going to use is already laid out in front of you to the exclusion of everything else.

I'd prefer if you simply made a Melee equivalent to Brawl's .gct editor, which can be found here

In addition to Achilles' response to you, I wanted to point out that you can also "manually" add/remove codes from the Mods Library by simply editing the text files in the Mods Library folder. The format is pretty simple. You can read more about it in the spoilers in the post directly following the OP.

 

[Achilles1515]

Were you maybe thinking about disassembling 80010000/80020000? They translate to "lwz r0,0(r1)" and "lwz r0,0(r2)"rather, than "lwz r0,0(sp)" and "lwz r0,0(rtoc)", respectively. I can change that to the latter though if it's preferred.

No, I was not talking about disassembling. Although a good option may be to enable that or, even more useful, being able to automatically convert the integer numbers into hex.

So instead of disassembling to
lwz r4, 10(r3)

It would be
lwz r4, 0xa(r3)

I say this because our community created data lists are in hex. And Dolphin shows hex.

I don't disassemble things that often though.

 

[oscat]

Any word on 20XX compatibility?

 

[DRGN]

Any word on 20XX compatibility?

Since compatibility is almost entirely about what code regions 20XX uses in the DOL, one could do a difference check between a vanilla 1.02 DOL and 20XXHP's DOL to find what areas are modified. Then, MCM could be reconfigured to avoid those areas by editing the settings.py file. (I recommend copying the settings file first, so you would have one to use with standard DOLs, and then another to use with 20XXHP.) However, I say "almost entirely", because one problem would still be injection points. Some codes, especially those that are variations of another or otherwise require a similar hook, might use the same injection point as a code within 20XX. Modifying the custom code regions in the settings file only affects where the program will save the code to be injected (as well as standalone functions). If multiple codes use the same injection point and are installed, only one of them will work (assuming the game even runs at all), as the branch(s) for the others will be overwritten. Only trial and error would then tell you if adding a code will work. But at least you would know that you're not overwriting 20XX's injected code, and this program will still work as usual.

In the next version of this program, there will be a new feature that detects whether two or more mods attempt to write to the same area for an injection point or static overwrite. This could solve a lot of hidden incompatibilities some existing mods have. For example, "Boot to Character Select Screen" and "Remove Special Messages" both write to the same place, so people who had both of these enabled mysteriously experienced one of these not working. However, such conflicts will only be detected with mods that are in the Mods Library, when attempting to save them to the game.

So for the conflict detection to catch incompatibilities between various user mods and 20XX's mods, 20XX's code would need to be in the Mods Library. This could exist as one giant 20XXHP mod, covering every modification 20XX has in the DOL. Or, it could be broken up as multiple smaller, more-descriptive modules, so that the user could enable just certain parts of 20XX. I know Achilles1515 uses MCM to handle some of 20XX's code, but I don't know how much, so I don't know how difficult it would be to put it all into a MCM Library, whether as one or multiple mods. If this method were done, the custom code regions wouldn't need to be modified. If Achilles did this, he would be able to identify which parts of 20XX can live entirely independently, and thus break up the modules for those that might want only parts. Alternatively, anyone could perform the diff I mentioned and create a 20XX mod to go into the Mods Library that covers all modifications. Once this feature is released, this would be a better method than modifying the settings file, which would only avoid overwriting custom code.

 

[Achilles1515]

Any word on 20XX compatibility?

Here is the quick and dirty. This is for 20XX 4.05 only (and not future versions).

Start with a brand new MCM download. This is your one dedicated to 20XX. Go to the settings.py file and modify the CommonCodeRegions to be this:

Go to the "Mods Library" folder and delete all the text files there. Create a new text file in that folder named "20XX codes.txt" or whatever you want. Now manually add any codes you want into MCM through the Tools tab and add them to that text file. After every code you add, go back to the Static Overwrites/Injection Mod tabs and click "Rescan for Mods" on the right. If it shows up green, then that means 20XX already has a custom code at that location...so don't use whatever code you just added. Go into the text file and delete it immediately before doing any saving of the DOL/ISO. If it doesn't show up as green, then it should be fine.

DRGN I almost solely use MCM for any new codes that are added. But there are still a few old ones that haven't been converted and are still manually injected into the DOL. Probably 90% of the codes are in MCM. Next 20XX release, I'll try and release my MCM mod list file. If I forget, remind me.

 

[DRGN]

I've been working a lot on rewriting major parts of this program. Among them, creating/editing mods, the parser, and how the Mods Library is displayed. The main tabs for the library are no longer "Static Overwrites/Injections Mods/Gecko Codes", and instead are whatever you want them to be. Each text file you put in the Mods Library now shows as its own tab, so you can organize them specifically for your project or however you think is best. So for example, shown below, for one of the tabs I simply have a "Characters.txt" file with just codes for characters.

It even allows for folders, so you can infinitely organize as you see fit.

Can't work on it this very moment, so I thought I'd spend the time explaining some of the new features. I'm hopeful that the ETA of this release will be in the next week or so.

 

[Punkline]

That's gonna be a great feature! I've accumulated a lot of clutter in my library that could really benefit from this. Looking forward to the new release~

I've never said my thanks in this thread, DRGN . I'm using this program constantly while hacking Melee. It's so easy to just experiment with this game now. Even when I'm not actively modifying a DOL--I keep it open to convert ASM, weird floats, offsets, and magus posts.

Thanks for making and maintaining this!

 

[DRGN]

Thanks! I hope you'll like the other new features in it just as well!

I've been excited about this update. Mostly for the new features and upgrades to the GUI. Also I fixed that bug you pointed out regarding ASM not aligned to 8 bytes failing assembly, and a few other bugs that were found.

Another big feature I've put work into is the new "Mod Construction" tab. When you click on the "Edit" button seen on the mods in the Mods Library tab (screenshots in my last post), it will open up the mod in this new tab, allowing you to edit it and save the changes back to the library at any time:

And the code shown there, or saved in the library, can instead be ASM rather than just hex! However, I think this would mostly just be useful when developing codes. Once a code is finished, I would still recommend converting the code to hex, because the code must be converted to hex when the program parses the library for mods. So if you were to save lots of mods all in ASM form, it would take noticeable longer to open the program.

Another cool new feature is the "Summary" tab, which will list all mods and standalone functions currently saved to your DOL file or game.

 

[DRGN]

Uhhhh... so this slowly turned out to be a huge update (~pretty much all of my Melee hacking work for the past 2-3 months). I'm excited to see things finally come together for another release though. A lot of core functionality has been rewritten; hence the bump to v3.

I think I've added some pretty useful features, and I've generally improved the logic of the existing core functionality. Parsing and the code saving logic each have had many major changes in order to work with the new library organization and Mod Construction features. And checking for installed mods and a few other things have been completely rewritten. It should still be 100% compatible with any games/DOLs you've edited using older versions.

I feel I've tested a good amount, but I obviously can't test all manner of use or input that this may be used for. As such, I'm considering this a beta for the time being.
So please create back-ups of your game or project files (your game's DOL of course, maybe your current Mod Library too) before starting with this.

If you notice anything from typos to explosions, please let me know, and I'll try to implement a fix ASAP.

Only available as 64-bit for now; will compile for 32-bit soon. (working on unbetafying first)

Changelist (from version 2.1 to 3.0):

- New nested tab interface for far-greater, user-customizable mod organization
- Mods can now be stored in library as ASM rather than just hex
- New "Mod Construction" tab, for better in-program mod editing and creation
- Mod Construction tab supports viewing/editing ASM with notes/comments
- Rewrote core code-saving logic to be more stable/concise/efficient
- Catches and warns you about mods that conflict with (overwrite) one another
- Rewrote checking for installed mods; should eliminate false-positives
- Improved error checking when saving codes to a DOL/ISO
- Improved support for Gecko codes (for 04 and C2 types)
- Now remembers and defaults to the directory of the last file loaded
- Processing/saving mods that include special branch syntaxes is much faster
- Standalone Functions now only need to be included with one mod
- Custom Branch Syntaxes can now be used with static overwrites
- Fixed parsing bug where branching to 0x8 would be mistaken as a RAM address
- Free space region ( 0x15CC, 0x1698 ) changted to ( 0x15F0, 0x1698 )
- Regions for custom code are now defined differently in the settings.py file
- More regions defined for injecting custom code (Tournament Mode, etc.)
- Regions defined in settings.py now have separate toggles within the GUI
- If new regions are added to settings.py, they will show up in GUI as well
- Empty lines now usable in descriptions
- Fixed (hopefully) all branch Hex -> ASM converter (disassembly) issues
- Improved disassembly performance (speed)
- Fixed a bug that caused ASM not aligned to 8 bytes to fail assembly
- Now zeroes-out unused areas of the free space regions upon saving
- New "Summary" tab, which shows mod totals and lists installed mods
- Mods parser now picks up comments preceded with "#" in descriptions, etc.
- "##" now used in Mods Library files to exclude comments from parser
- "Save As..." button/functionality added
- Progress indication added for save operations
- Can now just hit 'Enter' in the "ISO / DOL" text field to load that file
- Fixed 'Hitbox Displays Do Not Interpolate' (had bad formatting in library)
- Gecko codehandler moved to the settings.py file, for user modifications
- Better behavior on Gecko codes use (warns about overwriting required regions)
- New option to ignore hash-check on hex restoration (vanillaDolSafetyOverride)
- Fixed alignment for injection code saved directly after the Gecko codehandler
- Removed Herobrine​

Download in the OP.

 

[DRGN]

Couldn't stop.

Changelist (moving to v3.1):

- Standalone function definitions can be shared across specific, or all, game versions
- Standalone functions can now be the only thing in a mod; i.e. "Function Modules"
- Scanning for mods is faster
- Fixed an uncommon, odd GUI bug causing mods to render incorrectly
- Fixed small bug on Mod Construction tab dealing with PAL code updates
- Mods can now be filtered out from parsing by use of a '!' in first few lines*
- Further mod organization, and new mods added to library (& a few duplicates removed)
- Will now assume mods are disabled if a static overwrite occurs in used regions
- Message for mod conflict detection fixed to accurately report range ends
- Minor aesthetic fixes (folder tab icon disappearances)
- Fixed notes incorrectly stating that some gecko codes were unavailable
- Tooltip message added to explain the update button in the Mod Construction tab
- Summary tab now displays totals for how much space mods and standalone functions use
- Pressing CTRL-s on the Mods Library or General Settings tab saves your codes to the DOL
- Pressing CTRL-s on the Mod Construction tab saves the selected mod to your library
- If a mod is saved to a new file, Library is rescanned to include it
- "Open this File" button now works on empty Mods Library tabs
- Better validation of "Offset" input field in Mod Construction tab code changes
- The Share/Save functions will now attempt to retrieve missing Original Hex values
- Scroll position and tab selection are now preserved when rescanning Mods Library
- Now remembers last opened file type for the next time you want to open an ISO or DOL
- Added a check for mods writing a static overwrite or injection point to regions used for custom code
- much code cleanup, and testing, bringing this out of "beta"​

Spoiler: *Mod filtering/disable example

So that you don't have to comment out every single line if you'd like to temporarily disable a mod from parsing and showing up in the library.

There are a lot of checks in this program now to make sure that mods don't conflict, and to prevent users from doing something that will cause a mod to not work in-game or cause it to crash. As the number of mods out there continues to grow, I feel like the mod conflict detection will become increasingly useful. I want to point out however, that the conflict detection feature only works for mods written in the standard code format, not in Gecko Code form. Though it is pretty easy to convert them (instructions for doing so can be found in the second post in this thread).

Averting time to other projects now. (@Gentlefox) But major things planned for next release: Memory Card Exploit Maker tool (based on Achilles method explained here), and an overhaul to the summary tab, which could show you all the exact injection point, custom code, and static overwrite locations that are used for each mod saved in your DOL.

 

[FrisbeeMD]

Here is the quick and dirty. This is for 20XX 4.05 only (and not future versions).

Start with a brand new MCM download. This is your one dedicated to 20XX. Go to the settings.py file and modify the CommonCodeRegions to be this:

View attachment 115192

Go to the "Mods Library" folder and delete all the text files there. Create a new text file in that folder named "20XX codes.txt" or whatever you want. Now manually add any codes you want into MCM through the Tools tab and add them to that text file. After every code you add, go back to the Static Overwrites/Injection Mod tabs and click "Rescan for Mods" on the right. If it shows up green, then that means 20XX already has a custom code at that location...so don't use whatever code you just added. Go into the text file and delete it immediately before doing any saving of the DOL/ISO. If it doesn't show up as green, then it should be fine.

DRGN I almost solely use MCM for any new codes that are added. But there are still a few old ones that haven't been converted and are still manually injected into the DOL. Probably 90% of the codes are in MCM. Next 20XX release, I'll try and release my MCM mod list file. If I forget, remind me.

Is there a list you have of the current 20XX codes? The text file seems tedious and I essentially want to recreate most of 20XX and add certain things into MCM

 

[PracticalTAS]

DRGN Is it possible to use MCM to port a Gecko code between different versions of Melee? ie does MCM contain a map of memory addresses between versions?

 

[DRGN]

DRGN Is it possible to use MCM to port a Gecko code between different versions of Melee? ie does MCM contain a map of memory addresses between versions?

Yes. For example:

Pokémon Stadium - Disable Stage Transformations
[Zauron]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
PAL ------- 0x1CFD4C ---- 48003135 -> 60000000
1.01 ------ 0x1CDABC ---- 48002FA5 -> 60000000
1.02 ------ 0x1CE128 ---- 48003001 -> 60000000
1.00 ------ 0x1CD158 ---- 48002FA5 -> 60000000

Or,


Fountain of Dreams - Remove Side Platforms
- Removes (Disable) the Side Platforms
- Disables the 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)


Besides looking at examples in the Mods Library folder, details of how these are formatted can be found in the second post, in the spoiler 'Adding New Mods "Manually"'.

It doesn't convert addresses automatically, if that's what you mean (although theoretically that might be feasible).

As for your second question, well, not explicitly, but virtually, yes. As you may already know, the DOL is broken up into sections, which are each loaded into different places in RAM. Basically, within MCM, there is a map of these sections for each game version (created from information in the files' headers. you can learn more about this here). A few functions can then use these to calculate where any given dol offset will end up in memory, or conversely, to take any address in memory and determine where that place would be in any of the various dols. That's how the RAM Address Conversion tool in the tools tab works, and most importantly, how the program calculates branch distances when it's only given dol offsets.

 

[PracticalTAS]

I should have phrased the question differently. Given only a gecko code for one version of Melee, can I use MCM to port the code to the other versions of Melee?

Yes. For example:

Pokémon Stadium - Disable Stage Transformations
[Zauron]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
PAL ------- 0x1CFD4C ---- 48003135 -> 60000000
1.01 ------ 0x1CDABC ---- 48002FA5 -> 60000000
1.02 ------ 0x1CE128 ---- 48003001 -> 60000000
1.00 ------ 0x1CD158 ---- 48002FA5 -> 60000000

Starting with

$Disable Pokemon Stadium Transformations (1.02) [Zauron]
041D1548 60000000

How do I use MCM to get to the 1.00 version?

If I try to run a RAM address conversion on 0x801d1548, all four of the DOL offsets are shown as 0x1CE128

======

Starting with

$TAS Input Polling Fix (1.02) [Dan Salvato]
04432a5c 000a8000

How do I use MCM to get to the 1.00 version?

If I try to run a RAM address conversion on 0x80432a5c, all of the DOL offsets are "not found"

Edit: it's my understanding that if I had a list of 1.00 offsets (like 1.02 here: https://smashboards.com/threads/the-dol-mod-topic.326347/page-11#post-18976930), then this would just be a matter of addition and subtraction. Is this correct, and if so, does such a table exist?