Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
I forgot to reply to this, but I'm still having this issue.
I am also having this issue whenever I try to enter the debug menu whether through "Debug menu replaces Tournament Mode" or by setting the AR code in dolphin. It happens any time I enable any code using MCM and will continue to happen even if I disable the code with MCM and have no other codes enabled. For example if I copy my 1.02 iso of melee with nothing on it, go into debug mode it works fine but if I enable anything on the copy and disable it I can't go into debug anymore because of that error.
You most likely have the Debug Mode Region selected for use for custom code. You can check/change that by clicking on the Code-Space Options button:
Wow, I feel silly, I remember looking through that menu too. Anyways, thanks for the fast reply, all this stuff is super helpful me getting into modding. I got everything working normally again.
try using mcm 2.0, fixed my issues
This still has the downside (that will be true for any 20XX/MCM version, ATM) that not all codes in 20XX will populate in the program. MCM didn't exist when Achilles first started 20XX, so the main problem is that a lot of 20XX's changes are not included in any MCM library, and are just manually edited into the DOL independently. That's why you can only use the regions Achilles has defined in the settings file on the github (or in the region specified for it in the latest version of MCM), and why it's difficult to add codes, because there's a good chance you'll overwrite some other important custom code.
DraGon72097
Dpad up/down toggles rumble on CSS
NTSC 1.02
C22608D8 00000019
887F0007 2C030000
40820070 7C972378
57800739 40820010
5780077B 40820034
4800009C 7EE3BB78
38800000 38A0000E
38C00000 38ED9950
3D808037 618C8430
7D8903A6 4E800421
38800001 48000008
38800000 7EE3BB78
3D808015 618CED4C
7D8903A6 4E800421
38800001 989F0007
3C80C040 909F0014
C03F0014 C0428E0C
C01F000C EC01002A
D01F000C FC600850
FC030840 41810008
EC6300B2 D07F0014
4180001C C0828258
FC032040 41810010
38800000 909F0014
989F0007 889F0004
60000000 00000000
Welcome! There appear to be 2 problems here. I don’t have a PAL version to test this on atm, so let me know if these fixes don't work correctly.hi all!
first time posting on smashboards
so, i was trying to "transalte" this code from ntsc 1.02 to pal
Code:Dpad up/down toggles rumble on CSS NTSC 1.02 C22608D8 00000019 887F0007 2C030000 40820070 7C972378 57800739 40820010 5780077B 40820034 4800009C 7EE3BB78 38800000 38A0000E 38C00000 38ED9950 3D808037 618C8430 7D8903A6 4E800421 38800001 48000008 38800000 7EE3BB78 3D808015 618CED4C 7D8903A6 4E800421 38800001 989F0007 3C80C040 909F0014 C03F0014 C0428E0C C01F000C EC01002A D01F000C FC600850 FC030840 41810008 EC6300B2 D07F0014 4180001C C0828258 FC032040 41810010 38800000 909F0014 989F0007 889F0004 60000000 00000000
i've converted the first ram address in pal (C22608D8 to C226103C) like i did for some other codes, but it's not enough.
can someone help me?
it works :DWelcome! There appear to be 2 problems here. I don’t have a PAL version to test this on atm, so let me know if these fixes don't work correctly.
First, from the looks of things -- it appears that you’ve copied the C2 address and translated it as a DOL offset rather than a RAM address, giving you the incorrect C2 input. To translate a C2 code, you need to first translate the RAM address into a DOL offset, and then copy the offset into the conversion tool:
After the tool finds a matching DOL offset, copy it back into the RAM address conversion tool in the PAL field to generate a corrected RAM address. You can take the last 6 digits of the address and use it for your new C2 input:
So in this case, C2261078 is the "translation" you’re looking for.
It represents the RAM address 80261078.
Second, there are a couple of function calls in that code. Gecko codes need to load the addresses for these in halves in order to call them, so they usually take the form of 2 instructions. In this code, there are 2 cases of this that I can see in the instructions: “3D808037 618C8430” and “3D808015 618CED4C”. These create the addresses 80378430 and 8015ED4C when put together.
To get this code working on a PAL version of Melee, you would need to convert these addresses just like you would the C2 input.
Here's the code with all of the above conversions applied:
Dpad up/down toggles rumble on CSS
PAL 1.00
C2261078 00000019
887F0007 2C030000
40820070 7C972378
57800739 40820010
5780077B 40820034
4800009C 7EE3BB78
38800000 38A0000E
38C00000 38ED9950
3D808037 618C8334
7D8903A6 4E800421
38800001 48000008
38800000 7EE3BB78
3D808015 618CF4F0
7D8903A6 4E800421
38800001 989F0007
3C80C040 909F0014
C03F0014 C0428E0C
C01F000C EC01002A
D01F000C FC600850
FC030840 41810008
EC6300B2 D07F0014
4180001C C0828258
FC032040 41810010
38800000 909F0014
989F0007 889F0004
60000000 00000000
It looks like this injects code into a function that monitors for controller inputs on the CSS. The added instructions conditionally make calls to the mentioned functions 80378430 (HSD_PadRumbleActiveID) and 8015ed4c (Rumble_StoreRumbleFlag). I would assume these can be used to activate rumble on a given controller ID, and the conditions check for button press logic.
Oh, didn’t realize this! Thanks, I’ve edited my post to reflect this for anyone else who comes across it.
lis r3, 0x8015 # r3 = 0x80150000
ori r3, r3, 0xED4C # r3 = 0x8015ED4C
lis r4, 0x8016 # r4 = 0x80160000
subi r4, r4, 0x12B4 # r4 = 0x8015ED4Clis rA, 0x80XX # rA = 0x80XX0000ori rB, rA, 0xYYYY # rB = 80XX0000 | 0x0000YYYY
addi rB, rA, 0xYYYY # rB = 80XX0000 + 0x0000YYYY
subi rB, rA, 0xYYYY # rB = 80XX0000 - 0x0000YYYY
DRGN
-- this last scenario seems to run into a limitation of the offset conversion tool, at least when attempting to use the equivalent RAM addresses.
tufferugli
-- this last scenario might explain the odd hand behavior in the ported code you were describing. After taking another look at the code, I spotted a use of r13 before one of the function calls. I’ll look into this a bit later to see if I can make another correction to the ported code.
thanks a lot :DOh, didn’t realize this! Thanks, I’ve edited my post to reflect this for anyone else who comes across it.
Edit: Also, a few afterthoughts about other cues to look out for in cases of codes that won’t port correctly:
The combination of “lis” and “ori” is a very practical way to build addresses, and is probably what you’ll find in most codes -- but another way to do it is to use “addi” or “subi” in place of “ori”. This is what the game uses, so it may sometimes pop up in codes that need to be ported.
The cases for “subi” will require you to actually subtract the value to find the address, and can’t be read as plainly from the instructions as “ori” and “addi”:
Code:lis r3, 0x8015 # r3 = 0x80150000 ori r3, r3, 0xED4C # r3 = 0x8015ED4C lis r4, 0x8016 # r4 = 0x80160000 subi r4, r4, 0x12B4 # r4 = 0x8015ED4CGecko codes basically use this method of address building as a workaround for not being able to calculate their relative offset to a branch destination. This method of address building can also be used to reference data tables that are static, or create pointer addresses to things like callback functions. These will also need to be ported if they are included in codes.
This is trickier to look out for because there is no giveaway bctlr, blrl, or bctr instruction. The easiest way to spot these is by looking out for an instruction that looks like this:
-- where “rA” can be any register. The “80” is what you’re looking for, specifically. Finding this used in “lis” instructions is not a guarantee that you’ve found a global base address, but it is a good indication. To confirm, you need to find where rA ORed, added to, or subtracted from:Code:lis rA, 0x80XX # rA = 0x80XX0000
-- where “rB” can be any register. The use of “rA” from the previous lis instruction is what you’re looking to confirm.Code:ori rB, rA, 0xYYYY # rB = 80XX0000 | 0x0000YYYY addi rB, rA, 0xYYYY # rB = 80XX0000 + 0x0000YYYY subi rB, rA, 0xYYYY # rB = 80XX0000 - 0x0000YYYY
From this point, rB might be used as a base address for loading/storing data, passed as an argument to a function, stored as a pointer address value, etc.Registers r13 and r2 are are dedicated to storing a base address to a list of static variables and constants. These variables can be useful, or might even be necessary for some codes -- and they will need to be ported in codes that use them.
Rather than an address; these are offsets that need to be ported. Each is a negative offset from a static address stored in r2 or r13, and so the destination is a static reference.
In the current version of MCM (v4.0) attempting to reference these offsets as absolute addresses triggers an OOB error in the conversion tool. A workaround that I’ve used in the past is to find an example of an instruction that uses the offset you need to port, and to convert the address of that instruction instead. Then, read the offset used by the ported instruction to find the ported offset.
tufferugli
- I fully reversed the dpad rumble toggle code and posted some ports in Dan’s old thread for it. If you’re interested in learning exactly how the code works, I’ve also commented the source ASM and formatted it with descriptive labels and symbols. In addition to a PAL gecko code, I’ve made them available for all versions as DOL mods. These can be written more efficiently than gecko codes, and are installed to an ISO or DOL with Melee Code Manager.
DRGN
-- for 1.02 Melee, r13 = 804DB6A0. So, the equivalent RAM address for this offset would be 804D4FF0 (804DB6A0 - 66B0). Default r13 and rtoc data values are defined within the DOL, so wouldn’t it be possible for the offset conversion tool to reach these offsets when referenced as absolute RAM addresses? Currently, attempting to reference an offset like the above triggers this error:
I have no idea how to use this, so if you can respond to this than that'd be great. Also i'm trying this with 20XX so pls & thxDo 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 (game mode, stock count, etc., so they all finally stay remembered after restarting the game!). Supports DOL mods (including injection mods) as well as Gecko codes. Everything is done in a very easy-to-use interface, which simply presents you with a list of available mods, and allows you to install or uninstall them from your game with just a single click.
Cool stuff for average users:
Cool stuff for developers:
- Easiest and fastest way to add code-based mods to your game
- Use DOL mods instead of Gecko codes, to make your game run more efficiently
- No need to understand hex editing or ASM coding
- Easily adjust your game’s default settings (stock mode, items/stages, etc.)
- Provides visual ‘fill-meters’ to show how much space is available for custom code
- No need to extract/import the DOL from your game to update it
- Eliminates the old problem of mods' custom code overlapping one another
- Mod conflict detection feature identifies mods that may be incompatible with one another
- Avoid dealing with Nintendont/DIOS MIOS Gecko/.GCT code loader problems
- Easily create and add injection mods without needing to calculate branches
- Easily create and add static overwrites of any length
- Large game projects can be much more modular and manageable
- Automatic, efficient usage of available [user-defined] ‘free space’ used for custom code
- Relocates all custom code after editing if it uses more or less space
- Troubleshoot problems easier by quickly swapping out suspected mods
- Can use RAM addresses for DOL mods instead of searching for DOL offsets
- Easily convert Gecko codes to DOL mods using the above functionality
- New "Custom Branch Syntaxes" for easily making function calls (info below)
- Use "Standalone Functions" to reduce redundant code usage in the DOL
- Automatically looks up DOL ‘original’ code when adding a new mod via the GUI
- ASM to Hex converter and RAM Address to-from DOL Offset converter built-in
- Plus more converters and other useful tools in the Tools tab
Take a look!
View attachment 134970
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.
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.
You can give this program a DOL file, or an entire ISO (disc image file).
View attachment 134972
View attachment 134971
Before getting to the download, if this is your first time using this, please read the important info below first.
This will typically work best if you start using it 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. The Mods Library included in the download comes with many mods by default. And I will add more over time. However, if mods that you'd like to use are not included (of if you'd like to create new ones), you can easily add them using the interface in the Mod Construction tab. More info and details on this can be found in the post below this one.
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 two simple 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 (notes can be found in that file that go into more depth on how to do this). In any case, I recommend backing up your game just in case, or more specifically, your DOL file (the file that holds these codes), before using this program. There's a clearly visible button labeled "Export DOL", which you can use to do this easily. 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.
Gecko Codes are supported, but cannot be copy/pasted into the library text files exactly as-is, and must be slightly modified from the format commonly seen in .gct files. You can use the Mod Construction tab to input them, which will do this for you and save them to the library in the required format. Or you may convert them to DOL mods, which is a form that's more efficient for the game to run. Please see the post below this one on how to do this conversion. The Gecko codehandler used by MCM is a modified version of the one posted and discussed here.
Important note on making changes to mods: If you need to change the injection point that a mod uses or the location of a static overwrite, then you must first uninstall the mod from your game. This is necessary in order to prevent changes that are no longer used from the old version of the mod to be permanently included 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.)
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.
Melee Code Manager Downloads - v4.1:
64-bit
These programs take quite a bit of time. If you'd like to give back or show how much support there is out there for these, please consider donating!
You can do so via Paypal:
Or you can follow me on Patreon to support my main Melee projects.
Version 4.1:
- Updated the "Menu Text to Hex" tool, to include all Hiragana, Katagana, and Kanji characters- Greatly improved assembly performance (no longer using pyiiasmh to interface with EABI libraries)- Trying out disabling the linker during assembly (ba = 00000000); discuss. Might later re-enable- Added a new special syntax that can be used when writing codes, 'RAM symbols' (described in spoiler below)- Added a warning if any mods appear to be installed to disabled regions, with a prompt to enable them- Added a "Mod Search" button to the Mod Construction tab (same function as pressing CTRL-F) *- Comments on lines containing special branch syntaxes are now preserved- Fixed a performance regression regarding assembling unconditional branches that don't set any flags- Fixed a small GUI/highlighting related bug on the Item Switch window's "Item Frequency" dropdown- Improvements/additions to the Summary tab:- Added a context menu option to toggle whether it's sorting by offset (Advanced/Simple View) **- Added a context-menu option to toggle showing DOL Offsets or RAM Addresses- Added standalone function names to the Mods Summary tree when switched to Advanced View- 'View in...' features on a child item in the Mods Summary tree (in Simple View) now refers to parent item- 'View in...' features added to Standalone Functions tree when selecting a mod listing
- Audio output simplified (moved from pygame to pyaudio)- Removed warning of audio problems if no audio driver/device is available
* Used to search for Mods in your Mods Library by name. It was already previously available by pressing CTRL-F (since v4.0), but I figure it was mostly only known to those who noticed its introduction in the change logs, or by word of mouth.
** Switches between Simple View and Advanced View (Sorting by Offset) modes. Again, this feature previously existed (by clicking on the DOL Offset/RAM Address header), but was probably not widely known-about.
Version 4.0 ( 64-bit | 32-bit ):
- Support expanded to other GameCube and Wii games!*- Supports 20XXHP 4.07++**- The game's vanilla Debug Mode can now be used alongside Gecko codes- The Gecko codehandler and codelist can now be stored in user-defined regions***- Free-space code regions updated slightly:-[ Start area of Aux Code Regions changed to 0x407540 (NTSC 1.02)-[ Aux Code Regions end point moved to 0x4088B0-[ "20XXHP 4.07 Regions" added (do not use with other regions selected)
- Conflict with CrazyHand resolved (via AuxCodeRegions end point change above)- Free Space indicator divided into two; one for standard codes, one for Gecko- Gecko codehandler and codelist wrapper excluded from free space indicators- Code Free Space Indicators show exact used and available free space on mouse-over- CMD windows no longer briefly appear during mod parsing or ASM assembly/disassembly- Finally completely revamped the Summary tab:-[ See each and every change done to the DOL, as well as their locations-[ See how much free space each mod or individual change uses-[ Left-click the DOL Offset header to sort changes in order of offset-[ Right-click the DOL Offset header to view locations as RAM Addresses-[ New features: "Create Installed Mods List", and "Install Mods List"-[ Convenient 'View DOL Hex' button added
- Mod Search Feature! Press CTRL-F in Mods Library tab to search for mods by name- All hex inputs in the Tools tab now automatically remove spaces & line breaks- Mod Construction tab improvements:-[ The offsets shown can now be toggled between DOL Offsets or RAM Addresses-[ Undo/redo functionality added-[ Much more intelligent 'Unsaved' status detection-[ Fixed mods misunderstanding their installation status-[ Mouse-wheel scrolling over module list added-[ "New Hex" scroll position now preserved when switching between code change modules-[ GUI elements now properly fill space when expanding the window-[ Custom code length display added to static overwrites
- Tools tab GUI elements now properly fill space when expanding the window- Code Offset Converter updated:-[ Now can also be used with RAM Addresses (outputs in same form as input)-[ Fixed an issue reducing quickSearch=False (option in settings) match effectiveness-[ The available input fields now based on the DOLs present in the Original DOLs folder
- RAM Address Converter input fields now based on the DOLs in the Original DOLs folder- ToolTip module updated; fixes multi-monitor issues- Original DOL files no longer hash-checked before use (for hex restoration, etc.)- Code-Space Options button now brings the window to the front if it's already open- settings.py file changed. But GCM 4.x will still be backwards compatible with MCM 3.x files- Mod Library parsing features/improvements:-[ Folders/subfolders/files within the Mods Library that start with "!" are now ignored-[ Folders/subfolders/files starting with "+" are parsed exclusively (others ignored)-[ Pseudo-ops (assembly directives) can now be used within raw ASM code-[ empty lines (those with only line breaks) are now preserved in mod descriptions-[ Duplicate mod detection added. Previously could have caused problems when saving
- Errors are now output to "Error Log.txt"- "Restore Original DOL" feature added (Reverts the currently loaded DOL to vanilla)- Region details tooltip added to total region size labels in Code-Space Options window- "Save As..." button now always available- Improved logic for installing SFs; should add stability for recursive SF calls- Fixed: Mods that share many SFs no longer need to be ordered in the Mods Library- Fixed cases of some injection mods not being detected as installed- Fixed branching to standalone functions from long static overwrites- Fixed an obscure case where a conflict being detected could break an installed mod- Other fixes and behavior improvements- Lots of logic improvements and code refactoring, so we'll still need some testing*To use GCM with other games, see the spoiler regarding that in the second post of this thread.
**Use the "20XX 4.07++ Codes.txt" file from the GitHub, but rename the Sheik/Zelda CPU Disable Transformations mods so that they're not seen as duplicates. You don't need to use the settings.py file from there; just use the 20XX Regions that comes with this new MCM version.
***Using the Tournament Mode Region for the codelist grants over 260% more space for Gecko codes!
Version 3.2 (64-bit | 32-bit[/SIZE]):
- New option: "Update Default Game Settings Only". Compatible with 20XX!- A new text to hex converter for Melee's unique menu texts in the Tools tab*- Rumble options (per-player defaults) added to the Default Game Settings tab!- Simplified/cleaned-up default game settings code (now much easier to add more options)- Conflict detection feature now works between mods and the game's default game settings- Fixed a parsing bug for some long static overwrites created by the GUI- Fixed a bug stopping an automatic rescan of enabled codes after changing program options- Fixed installation false-positives occurring on some codes using static overwrites- Fixed the Code Offset Conversion input (was broken in just v3.1)- Improved some messages & dialog boxes to the user- 32-bit build also available!
*The dictionary for this converter resides in the settings.py file, so you may modify it if you want to figure out more characters.
Version 3.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 (example)- 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 reserved regions- Message for conflicting mod 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 the 3.0 "beta"
Version 3.0 (considered beta, since there are so many new changes):
- 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
Version 2.1 (x64 | (x86):
- 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
Version 2.0 (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.
- - -
Shout-outs and special thanks to @Achilles1515 and @Michael Ashby for their support!
And also thanks to @shuall, @_glook, @Jorgasms, @SinsOfApathy , and others, who each stopped their busy hacking to answer questions or give suggestions during my initial design stages. And to
Punkline , for bug reporting/documenting and other feedback.
I plan to put this on Github at some point, but feel free to PM me for the source code for now.
Have you tried reading the second post?
Oops; didn't see this.
Oh, I didn't even realize that feature was case sensitive, haha. No need for it to be. Whoops. I'll change that for the next version, so it's easier to use with Dolphin.
Minor bug I found, in v4.2.
C2242B10 00000016
3DE0807D 61EF71A0
81EF0000 81EF0000
3E00807D 621071A8
82100000 82100000
823F0008 8231001C
C1F10000 C2110004
C2310008 C24F0000
C26F0004 C28F0008
EDEF9028 EDEF03F2
EE109828 EE100432
EDEF802A EE31A028
EE310472 EEB1782A
C1F10000 C2110004
C2310008 C2500000
C2700004 C2900008
EDEF9028 EDEF03F2
EE109828 EE100432
EDEF802A EE31A028
EE310472 EDF1782A
FC0FA840 38A00001
41800008 38A00000
60000000 00000000MainBoss Target Closest Player Inject @ 80242B10 || ORIGINAL: lwz r5, 0x3148 (r13)
lis r15, 0x807D
ori r15, r15, 0x71A0
lwz r15, 0x0(r15)
lwz r15, 0x0(r15)
lis r16, 0x807D
ori r16, r16, 0x71A8
lwz r16, 0x0(r16)
lwz r16, 0x0(r16)
lwz r17, 0x8(r31)
lwz r17, 0x1C(r17)
lfs f15, 0x0(r17)
lfs f16, 0x4(r17)
lfs f17, 0x8(r17)
lfs f18, 0x0(r15)
lfs f19, 0x4(r15)
lfs f20, 0x8(r15)
fsubs f15, f15, f18
fmuls f15, f15, f15
fsubs f16, f16, f19
fmuls f16, f16, f16
fadds f15, f15, f16
fsubs f17, f17, f20
fmuls f17, f17, f17
fadds f21, f17, f15
lfs f15, 0x0(r17)
lfs f16, 0x4(r17)
lfs f17, 0x8(r17)
lfs f18, 0(r16)
lfs f19, 0x4(r16)
lfs f20, 0x8(r16)
fsubs f15, f15, f18
fmuls f15, f15, f15
fsubs f16, f16, f19
fmuls f16, f16, f16
fadds f15, f15, f16
fsubs f17, f17, f20
fmuls f17, f17, f17
fadds f15, f17, f15
fcmpo cr0, f15, f21
li r5, 1
blt 0x8
li r5, 0
-==-
BossTesting
[dream]
Revision ---- DOL Offset ---- Hex to Replace ---------- ASM Code -
NTSC 1.06 --- 0x802A6DA8 ---- 80AD3148 -> Branch
bl <bossmagic>
------------- 0x80242B10 ---- 80AD3148 -> Branch
bl <bossmagic>
<bossmagic> NTSC 1.06
3DE0807D 61EF71A0
81EF0000 81EF0000
3E00807D 621071A8
82100000 82100000
823F0008 8231001C
C1F10000 C2110004
C2310008 C24F0000
C26F0004 C28F0008
EDEF9028 EDEF03F2
EE109828 EE100432
EDEF802A EE31A028
EE310472 EEB1782A
C1F10000 C2110004
C2310008 C2500000
C2700004 C2900008
EDEF9028 EDEF03F2
EE109828 EE100432
EDEF802A EE31A028
EE310472 EDF1782A
FC0FA840 38A00001
41800008 38A00000
60000000 00000000Code that's injected does not branch back automatically (which was an intentional design, partly for cases where it might not be desired). So in your case, those injections are being branched to, executed, and then because injection code is stored end-to-end, code execution is just going to the next block of code, which is just another branch because that's what "bl <bossmagic>" assembles to. A branch back to the injection site will be added automatically if the last instruction in the injection code (not the SF) is a standard/unconditional branch or a null word (opcodes 48/49/4A/4B/00). This is why you might notice that most injection mod code in MCM ends with a branch (even if it's just 48000000, technically a branch to nowhere) or an empty word.Minor bug I found, in v4.2.
The refresh button (for number of bytes) does not work for standalone functions. It will stay at last counted value until the mod is saved, and MCM is restarted.
Maybe a major bug / or more likely, I do not understand proper usage of standalone functions:
I think I either lack the understanding for how to properly use standalone functions or there is an issue with the feature.
I took a look at Impossible Cancel v0.20 (library) by Punkline to understand.
My situation is I have a C2 gecko code that I was injecting at 5 different addresses, but other than the C2[address], the code was identical.
Seems like a perfect candidate for standalone function, right?
Just for transparency here is the code and asm source::
Gecko Code:
ASM Source:Code:C2242B10 00000016 3DE0807D 61EF71A0 81EF0000 81EF0000 3E00807D 621071A8 82100000 82100000 823F0008 8231001C C1F10000 C2110004 C2310008 C24F0000 C26F0004 C28F0008 EDEF9028 EDEF03F2 EE109828 EE100432 EDEF802A EE31A028 EE310472 EEB1782A C1F10000 C2110004 C2310008 C2500000 C2700004 C2900008 EDEF9028 EDEF03F2 EE109828 EE100432 EDEF802A EE31A028 EE310472 EDF1782A FC0FA840 38A00001 41800008 38A00000 60000000 00000000
Being unfamiliar with MCM this is my process:Code:MainBoss Target Closest Player Inject @ 80242B10 || ORIGINAL: lwz r5, 0x3148 (r13) lis r15, 0x807D ori r15, r15, 0x71A0 lwz r15, 0x0(r15) lwz r15, 0x0(r15) lis r16, 0x807D ori r16, r16, 0x71A8 lwz r16, 0x0(r16) lwz r16, 0x0(r16) lwz r17, 0x8(r31) lwz r17, 0x1C(r17) lfs f15, 0x0(r17) lfs f16, 0x4(r17) lfs f17, 0x8(r17) lfs f18, 0x0(r15) lfs f19, 0x4(r15) lfs f20, 0x8(r15) fsubs f15, f15, f18 fmuls f15, f15, f15 fsubs f16, f16, f19 fmuls f16, f16, f16 fadds f15, f15, f16 fsubs f17, f17, f20 fmuls f17, f17, f17 fadds f21, f17, f15 lfs f15, 0x0(r17) lfs f16, 0x4(r17) lfs f17, 0x8(r17) lfs f18, 0(r16) lfs f19, 0x4(r16) lfs f20, 0x8(r16) fsubs f15, f15, f18 fmuls f15, f15, f15 fsubs f16, f16, f19 fmuls f16, f16, f16 fadds f15, f15, f16 fsubs f17, f17, f20 fmuls f17, f17, f17 fadds f15, f17, f15 fcmpo cr0, f15, f21 li r5, 1 blt 0x8 li r5, 0
New Mod -> Import Gecko Code -> Import
This add an Injection entry. I did the same for another of the same code just at a different injection address, via importer.
Now I have two injection entries. Opening it reveals they have the same converted code contents.
So, I cut the content, make a new Standalone function and paste.
I call it bossmagic
In my other two injection entries I put in
"bl <bossmagic>"
Here are pictures for reference:
![]()
![]()
Save, run.
Instead I'm greeted with this:
![]()
The bottom part is one of the injects, it branches directly to another b instruction returning me to then next instruction.
I do see my standalone function right above it, but it never b's to it.
Lastly here is the output / share button version of this:
I brought this up on the discord and psiLupan has been trying to help figure out what's wrong. Any help would be appreciated !Code:-==- BossTesting [dream] Revision ---- DOL Offset ---- Hex to Replace ---------- ASM Code - NTSC 1.06 --- 0x802A6DA8 ---- 80AD3148 -> Branch bl <bossmagic> ------------- 0x80242B10 ---- 80AD3148 -> Branch bl <bossmagic> <bossmagic> NTSC 1.06 3DE0807D 61EF71A0 81EF0000 81EF0000 3E00807D 621071A8 82100000 82100000 823F0008 8231001C C1F10000 C2110004 C2310008 C24F0000 C26F0004 C28F0008 EDEF9028 EDEF03F2 EE109828 EE100432 EDEF802A EE31A028 EE310472 EEB1782A C1F10000 C2110004 C2310008 C2500000 C2700004 C2900008 EDEF9028 EDEF03F2 EE109828 EE100432 EDEF802A EE31A028 EE310472 EDF1782A FC0FA840 38A00001 41800008 38A00000 60000000 00000000
-==-
BossTesting
[dream]
Revision ---- DOL Offset ---- Hex to Replace ---------- ASM Code -
NTSC 1.06 --- 0x802A6DA8 ---- 80AD3148 -> bl <bossmagic>
------------- 0x80242B10 ---- 80AD3148 -> bl <bossmagic>
<bossmagic> NTSC 1.06
3DE0807D 61EF71A0
81EF0000 81EF0000
3E00807D 621071A8
82100000 82100000
823F0008 8231001C
C1F10000 C2110004
C2310008 C24F0000
C26F0004 C28F0008
EDEF9028 EDEF03F2
EE109828 EE100432
EDEF802A EE31A028
EE310472 EEB1782A
C1F10000 C2110004
C2310008 C2500000
C2700004 C2900008
EDEF9028 EDEF03F2
EE109828 EE100432
EDEF802A EE31A028
EE310472 EDF1782A
FC0FA840 38A00001
41800008 38A00000
4E800020Right, I should definitely be using static overwrites for this particular case. I had done that before (code was identical to what you posted) and it does work.
38600008 [aka li r3, 8]
bl <bossmagic>
38600008 [aka li r3, 8]as.exe lets you specify multiple .include paths. It made me wonder: would it be possible to use this to make the .include directive -- when used in MCM -- search for file resources in a way that prioritizes the directory that the code was installed from; followed by backup directories?*.s, *.asm, *.i, *.inc or other assets locally with a code without having to stuff a bunch of weird files into the MCM root directory. This might be particularly useful for building projects that can be easily updated and maintained as a set of modules.*.txt) was loaded from, in the Mods Library.include find files in the root MCM directory. I believe this would be useful for development purposes, as it currently is. Maybe it could be given a special folder instead of directly using the active directory directly, or a selectable folder like the Mods Library..include failures, and just generally provide a less messy user experience.
Oh, that's pretty cool. Yeah, the idea and the priority list you suggested sounds like it would work well. The '.include' folders make sense too.Heyas.exelets you specify multiple.includepaths. It made me wonder: would it be possible to use this to make the.includedirective -- when used in MCM -- search for file resources in a way that prioritizes the directory that the code was installed from; followed by backup directories?
This would make it possible to include prerequisite*.s,*.asm,*.i,*.incor other assets locally with a code without having to stuff a bunch of weird files into the MCM root directory. This might be particularly useful for building projects that can be easily updated and maintained as a set of modules.
Considering the newer Mods Library system folder mechanics introduced recently, I think it would be particularly advantageous to use a priority that went something like:
Level 1 would be whatever the current MCM version is using -- which currently lets
- Override- files in the active directory take precedence over all others, for overriding purposes
- Local - files in the same directory that the code (
*.txt) was loaded from, in the Mods Library- Mods Library - an optional default local to the currently specified Mods Library directory
- Default - a final default in the MCM directory, for tries that missed all other catches
.includefind files in the root MCM directory. I believe this would be useful for development purposes, as it currently is. Maybe it could be given a special folder instead of directly using the active directory directly, or a selectable folder like the Mods Library.
I figure that since folders can be hidden from the regular MCM parser with a '.' character, an optional folder called ‘.include’ could then contain any files for levels 3 and 4.
If it were possible to then preemptively inform MCM of what files will be loaded within a code as a form of redundant metadata in the code description (maybe specified as file path names somewhere around the code title/desc/authors tag) -- then the program could simply skip codes that would fail to find the stated prerequisite files. I figure they could then appear 'disabled' in the same way that codes for the wrong version of Melee are disabled; thereby hiding the errors normally caused by.includefailures, and just generally provide a less messy user experience.
What do you think of these ideas?
---
On a sort of similar note: what do you think about the idea of some kind of protocol for invoking the linker when assembling specific codes?
My understanding is that this slows down the parse, and is therefor undesirable in most cases since the linker is usually not needed for most codes -- but there are a few features in ASM that can only be used with the linker enabled, and they might be helpful for assembling larger projects in MCM.
Would it be possible to allow for individual exceptions with some kind of special token or statement made as part of the code description info, or something? Or, perhaps at the very beginning of a standalone function or injection code container, for individual ASM programs within a single code?
.include dependencies could just be checked for and resolved automatically at that time, using the priority you suggested, and I don't think an additional tag/info field would be needed with the code. Or were you suggesting that explicitness for testing/convenience purposes? Or maybe it would be useful in case you want different files to use different dependencies by the same name (again, likely for testing, since that otherwise sounds like a naming fiasco to be avoided). In either case, there could be a button somewhere to check exactly what dependencies or include paths would be used. Having them appear disabled with a warning displayed on them in the case of missing files is also a good idea.
.include "primlite.s" could then also place the string "primlite.s" somewhere in a place where MCM could see it, and then MCM would check the available paths for a match. It would be totally optional since the parse can just succeed normally without it -- but would afford avoiding a list of errors in cases of failure..incbin directive could all be defined like this without really invoking a dependency hell when applied to specific codes -- and could potentially be very useful..include from inside the first module, like a chain. This could use a target directory that is selected after being invoked from a base module -- allowing a program that intends to use some custom set of files to explicitly state the subdirectory name it wants to use; or something like that..include the symbol information into any code that might need it. That way, carefully named offsets in the included file can be used like unique keywords for loading variables from arbitrarily stacked allocations from a common base address; even if the variables change locations from configuration to configuration. This allows the order of each group of variables to not matter -- only the consistency of the names of each variable.# in file “.RTStackSnacks\Snacks.txt”
enum, 4, myASIDFunction.xASID, myASIDFunction.xASTID;
myASIDFunction.prereq = 1
# allocate 2 variables and a prereq symbol for the function "myASIDFunction" <myASIDFunction>
.include "RTStackSnacks.s"
enum r3, 1, rProperty, rASTID, rCount, rSnacks; xNextASTID=-0x5228
# local symbols
.ifdef myASIDFunction.prereq
getsnacks rSnacks
# rSnacks = base address of RT Stack Snacks
stw rProperty, myASIDFunction.xASID(rSnacks) # this is an imported symbol
lhz rASTID, xNextASTID(r13) # this is a locally defined symbol
stw rASTID, myASIDFunction.xASTID(rSnacks)
# pack a snack into rSnacks, for later
.endif
# do not assemble instructions if missing .prereq
blr
NTSC 1.02 ----- 800693d4 ---- 7c982378 -> Branch
# Injection applies any usage of myASIDFunction to a transformation of the next Action State
.include "RTStackSnacks.s"
rASID=r4; rSnacks=r12; xNextASTID=-0x5228
.ifdef myASIDFunction.prereq
getsnacks rSnacks
lwz r0, myASIDFunction.xASTID(rSnacks)
lhz r15, xNextASTID(r13)
cmpw r0, r15
bne- _return
lwz rASID, myFunction.xASID(rSnacks)
# if transition ID matches, then get your snack back
_return:
li r0, 0
stw r0, myASIDFunction.xASTID(rSnacks)
# destroy record
.endif
# do not assemble instructions if missing .prereq
mr r24, rASID
.long 0
.ifndef myASIDFunction.prereq; .error "myASIDFunction requires variables that are missing from .RTStackSnacks\\Snacks.txt"; .endif . That way, even if the correct module is detected, the things that a given code needs from the module can be individually tested for and throw more specific errors about what is missing.
Sounds good. Though due to work, family stuff, and travel, I likely won't be able to look at it this month. I also may release a smaller update without this first, so I can then release other work. So it may be a little while. I'll let you know if I have any questions or when I have a test build, of course.
I followed the instructions to inject this into my 20XX Training Hack Pack however where would I be able to check to make sure it was successful or that UCF is on? I assume it doesn't add a sub-menu into the Training Hack Pack options since I didn't see anything in there. Sorry for being a noob, I just started using MCM today.
Adding to what DRGN answered:
1) Did you try adding UCF as an injection mod? I attached a properly converted (NTSC 1.02) UCF 0.73 injection mod text file to this message. You may add the file to the Mods Library folder.
2) Remove (or exclude) the default mcm library mods from the Mods Library when editing 20xx to avoid conflicting codes interfering.
Would I be able to private message you regarding this? I'm close I think but just need help to see what I am overlooking. I'm attempting to add it to my 4.07++ Training Hack Pack. Your help would be greatly appreciated.
DRGN
, please consider this for MCM! It should be compatible with the extended dol, and adds an extra ~0x40800 bytes of usable space for gecko codes. This means that Melee would have about 0x60000 bytes of free space in total, with ~0x19800 of it being for DOL mods, and ~0x40800 of it being for gecko codes patched with the code handler. I will have updates for SME-CODE in the near-ish future, so if you decide to support this in MCM, please be aware of new versions.