SD Remix - 3.3 Full with Slippi Rollback Released!

[CeLL]

I see. From what I heard in the past, it was previously considered unlikely because of memory constraints, what with the largest official memory cards only supporting around 8MB or so, of which a 20MB patch couldn't possibly fit.

With this newer, more compact patch, and assuming that the know-how for file replacements becomes a reality, loading SDR from a memory card is still a possibility, right?

Well it's not so simple as a patch when you're not dealing with the ISO. For the memory card method, we would need the whole 16.7 MB for complete file replacements, afaik.

 

[_glook]

So I was messing with the 1.2 version of SD Remix and it turns out, neither Captain Falcon nor Ganondorf can act if they connect with their Side+Bs, whereas they're supposed to be able to. Does anybody have these changes on hand for 1.2?


More directed at @ sdremix_troubleshooter , what's the thought about adding in more usability DOL mods? For instance, I think it would be good to put in some of the DOL suggestions that Achilles mentioned (particularly the camera mode unbounded). Stage striking is also something I really want, as it's awesome and it has no apparent drawbacks to include. I also think the dynamic lagless FoD code would be nice, though I think you said you were fine with it already.
However, there are a couple of mods that I think would be great, but mess with the UI in some way. I think the handicap actually be stock control and auto being crew battle control would be great, but it does take away functionality from the core game, which may or may not be something that's okay. However, the people who play SD Remix probably don't have much use for the default handicap mode, so it might be worth it. If it's really desired, maybe another menu that's like the debug menu can be created to toggle these settings so there's no loss of functionality. This might also be considered getting into more of "Melee+" territory rather than SD Remix, but I think this is still a gray enough area that maybe it can be done without compromising the vision of the mod.
Along the same lines, I also think it would be nice to have my ties broken by percentage code:

Spoiler

$Ties broken by percent
C21A415C 0000003B
3803FFFF 2C000003
408201CC 2C0B0020
418201C4 3821FFDC
3A010004 3E208045
62313080 3E408047
62529E00 3A800000
7EA1A214 9A950000
8AB20000 B2B00000
2C15004E 41A00018
8AB20001 B2B00002
82B100B0 82B51890
92B00004 3A100008
3A310E90 3A5200A8
3A940001 2C140004
4082FFC0 3A200000
7E418A14 8A520000
7E348B78 2C140000
41820070 7EA1A214
8AB5FFFF 56501838
3A100004 7E100A14
56A41838 38840004
7C840A14 A0B00000
A0C40000 7C053000
41810030 41A0003C
A0B00002 A0C40002
7C053000 4180001C
41A10028 80B00004
80C40004 7C053000
41A00008 48000014
7E01A214 9AB00000
3A94FFFF 4BFFFF90
7E81A214 9A540000
3A310001 2C110004
4082FF70 3AA00000
3A800001 7CA1A214
8885FFFF 88A50000
54B11838 3A310004
7E310A14 A2510000
2C12004E 41A00078
54901838 3A100004
7E100A14 A0D00002
A2510002 7C069000
40820050 3CC08047
60C69E00 1E4400A8
7E523214 80D00004
80F10004 7C063800
88D20001 40800008
38C60001 3CE08047
60E79E00 1E4500A8
7E523A14 98D20001
98D20002 2C060000
40A20008 3AB50001
3A940001 2C140004
4082FF6C 2C150000
4082000C 38600005
38000004 38210024
3A000000 3A200000
3A400000 3A800000
3AA00000 00000000

Basically, if during any match during any mode (including time, stock, coin, and bonus modes), if a tie occurs, this code separates the tied players by real damage (the float value at 0x1890 in the player struct, not the displayed percent in the player block which is an integer). A side effect of all this is that if both characters die at the exact same time in stock mode (upthrow with Kirby on Rainbow cruise at 3 seconds in for a reproducible case of this), the character with the lowest percentage on death is declared the winner. There's a few benefits to this code. Firstly, you don't have to remember the percentage that you were at when the timer runs out and the results screen automatically tells you who won (by percent). Second, it skips sudden death entirely when you're tied by stock, points, or coins when the time runs out (which is a small usability improvement). Lastly, I'm using the real value for damage, which is a floating point value, which you normally wouldn't be able to see in the game, which rounds damage to the nearest integer to display to you. This makes a tie happening very unlikely, unless both players were at 0% when the timer ran out. The disadvantage is that if people like the old tiebreaker method that didn't depend on percentage (which can be understandable), this would automatically declare the winner when it would be a tie in the old version. However, I think since SD Remix was born from the competitive community, it would be nice to have competitive elements like this in it. Another disadvantage is that the code is enormous, so hopefully there's enough room on the DOL to fit it in.
I can also try and figure out how to make sudden death actually a 1 minute match with no bombs. The nice thing about v1.2 over 1.0 is that it sets the stock count to 1 for each character instead of carrying over the remaining stock count for the match, so you don't even have to worry about that 1.0 quirk. That being said, it has the same disadvantages in that if people liked the normal sudden death, it would be taken out. This might not really be worth it to figure out, though, if you use the percent tiebreaker code I provided, since sudden deaths would become exceedingly rare.

I see. From what I heard in the past, it was previously considered unlikely because of memory constraints, what with the largest official memory cards only supporting around 8MB or so, of which a 20MB patch couldn't possibly fit.

With this newer, more compact patch, and assuming that the know-how for file replacements becomes a reality, loading SDR from a memory card is still a possibility, right?

The patch file from 1.0 to SDR is actually only 80kb. I don't know how much of that is DOL changes, but the DOL changes are quite easy to do. The config changes are possible as well, PlCo.dat is loaded into memory, which you can poke. It's the stage and character changes that are problematic. You'd have to first create or port the patching code into the dol and hope to god that it fits (xdelta.exe itself is 303kb, so it might fit but creating a patching algorithm in ASM is a daunting task, and you'd probably have to roll your own simplified algorithm, which wouldn't get you down to the 80kb that xdelta gets you). Then you'd have to pre-generate your patch file using the reverse of the algorithm you injected into the DOL using the memory card method. Then you'd have to find the place that actually loads character/stage files (I know that function 0x8039063C seems to be run whenever it SEEMS to be trying to get things from disc, though I could be wrong about that, but more research needs to be done to know the exact function doing the loading, which might be more difficult if the loading is done on separate threads). THEN you need to DOL inject that function to go to your patcher, which interjects the disc loading code and checks the location on disc it's reading from and whether that's a location that needs to be replaced with whatever is in your patch file. It's a lot of work, and it's not likely to be done anytime soon. And even after doing all this, you've likely increased the loading times by an order of magnitude.

 

[_glook]

Here's the tl;dr:

Falcon and Ganondorf can't act after their Side+B in v1.2 based SDR anymore. Does anyone have this code?

Can the following dol mods be added?
- Unbounded Camera Mode (and event unlock)
- Stage striking
- Dynamic Lagless FoD
- Ties broken by percent

Loading SDR from a memory card: It's hard.

 

[CeLL]

Here's the tl;dr:

Falcon and Ganondorf can't act after their Side+B in v1.2 based SDR anymore. Does anyone have this code?

Can the following dol mods be added?
- Unbounded Camera Mode (and event unlock)
- Stage striking
- Dynamic Lagless FoD
- Ties broken by percent

Loading SDR from a memory card: It's hard.

Captain Falcon - Raptor Boost Enters "Fall" Action State Instead of "FallSpecial" (1.02) [Achilles]
040E39D0 4BFE8D61
040E3AEC 4BFE8C45
040E3CD0 4BFE8A61

 

[_glook]

Also, I imagine this is much more of a Melee+ type of hack, but just throwing out there that maybe some of the degenerative gameplay mechanics can be dealt with, like ledge stalling:

I imagine this would be unwelcome given SD Remix's goals, but maybe it can be offered as a side build as a Melee+ with SD Remix characters build (or something).

 

[_glook]

So making it so that PK Thunder doesn't disappear on death or on getting hit can partly be accomplished by doing this:

@802abcb4, write 38600000

However, the tail still disappears, so we're not done quite yet.

 

[_glook]

So I got PK Thunder working. Essentially, these are the new RAM addresses:
802abcb0 is 4bfc7481
802abcb4 is 60000000

This translates to at DOL 2A8890, overwrite with 4bfc748160000000.

I also applied the falcon/gdorf side+B buffs:
E05B0 = 4BFE8D61
E06CC = 4BFE8C45
E08B0 = 4BFE8A61

From sdremix_troubleshooter's posts, I'm assuming the Dynamic FoD mod is welcome enough, so I went ahead and included it anyway (it totally wasn't because I was too lazy to remove it, lol).

I've uploaded the updated files as ProbablySDR.zip. I don't think there's anything left to port, but I haven't done extensive testing either, so I don't know for sure (which is why it's called ProbablySDR.zip).

Assuming there aren't any other issues left over, it would be interesting to see which other DOL mods would be welcome. Again, I have a strong preference to include stage striking, and I think it would be nice to break ties by percent as well. The unbounded camera thing and event modes unlocked would be nice as well. Having all players be able to control the debug menu would be nice too, especially if the debug menu is going to be messed with a bit to get some of the other nice toggles.

If toggles are going to happen from the debug menu, like 20XX, I have a preference for including Handicap is Crew Battle mode (by Jorgasms), my Bombs Away code, and my ledge invincibility attrition code. But that's my personal preference.

Edit: Also, I think lowercase name tags, as well as longer name tags, would be nice. I think little things like this could make it more attractive for people to want to go and install it, as it has more than just character changes, but usability improvements in general.

Edit 2: By the way, if anybody wants to take a whack at applying character patches on the fly to pave way for Memory Card exploit SDR, it seems character files are being read into memory at code locations 800d0fc8 and 800d10a8.

 

[sdremix_troubleshooter]

I will test this by Monday. If it looks good, I will release it and you will receive due credit for your dedication and passion, glook.

For the record, I am okay with Stage Striking, Unbounded Camera, and All Events Unlocked.

Crew Battle Mode is interesting, but only if it's toggleable on/off in-game.

 

[_glook]

I will test this by Monday. If it looks good, I will release it and you will receive due credit for your dedication and passion, glook.

For the record, I am okay with Stage Striking, Unbounded Camera, and All Events Unlocked.

Crew Battle Mode is interesting, but only if it's toggleable on/off in-game.

Excellent, in that case, you should test with this new set of files, as it has Stage Striking, Unbounded Camera, and All events unlocked. Attached as ProbablySDR2.zip

I might put in a version with a bunch of other changes if you want to take a look at that, with things in toggles.


That being said, does anybody have a good resource on altering the Debug Menu? I know it's possible because 20XX does it, but I couldn't find a guide in the sticky about it.

 

[CeLL]

That being said, does anybody have a good resource on altering the Debug Menu? I know it's possible because 20XX does it, but I couldn't find a guide in the sticky about it.

http://smashboards.com/posts/18927862

 

[Quillion]

When 3.2 gets released, can we get it on the front page of SmashBoards?

 

[DRGN]

The way you describe it sounds pretty useful for DOL code management, though it doesn't look like it currently supports injection of arbitrary ASM Hex directly in the progam (I haven't used it so I don't know how well it does the automatic branch recalulations). Do you have to save the hex for the ASM somewhere in a file with the program or is that stuff hard coded in?

& @ sdremix_troubleshooter

How do you personally use the standalone ASM? (like how is it referenced or used by your other codes?) Or is it actually completely standalone and doesn't ever need to be branched to or referenced? (e.g. executed at runtime and then not needed to run again.)

The idea for the library of codes offered in the program is that the standard user wouldn't need to open the text files very often (obviously the interface is the main deal); they're just there so anyone can add new mods without having to wait for updates to the program. I'd like to add every code out there to the library, so they're all included by default in the program. And anyone who wants to make their own custom game can just pick and choose what they want from within the list in the program, as well as easily set all of their own custom default game settings. Plus all of the dol mods would then be collected together in one place. I'm not sure if there are many people really interested in all of this though. I know there's the collection in the DOL thread, but it's pretty incomplete.

This makes things really easy for inexperienced hackers. But experienced hackers could still benefit from it too, how I described before about not needing to worry about calculating branches or moving functions. And also, I plan to include in the next update a few other handy tools for working on new mods, such as number converters (hex, decimal, 32/64-bit signed floats), and offset conversions between game versions, and for RAM addresses.

 

[_glook]

& @ sdremix_troubleshooter

How do you personally use the standalone ASM? (like how is it referenced or used by your other codes?) Or is it actually completely standalone and doesn't ever need to be branched to or referenced? (e.g. executed at runtime and then not needed to run again.)

The idea for the library of codes offered in the program is that the standard user wouldn't need to open the text files very often (obviously the interface is the main deal); they're just there so anyone can add new mods without having to wait for updates to the program. I'd like to add every code out there to the library, so they're all included by default in the program. And anyone who wants to make their own custom game can just pick and choose what they want from within the list in the program, as well as easily set all of their own custom default game settings. Plus all of the dol mods would then be collected together in one place. I'm not sure if there are many people really interested in all of this though. I know there's the collection in the DOL thread, but it's pretty incomplete.

This makes things really easy for inexperienced hackers. But experienced hackers could still benefit from it too, how I described before about not needing to worry about calculating branches or moving functions. And also, I plan to include in the next update a few other handy tools for working on new mods, such as number converters (hex, decimal, 32/64-bit signed floats), and offset conversions between game versions, and for RAM addresses.

I still haven't had much of a chance to mess with your program, but I like the idea, just as a response to something you said:

While including it in the program is nice, I personally think it's more elegant of a solution to have a plugin or extension-like system where each DOL mod is its own file, which holds some sort of data (Gecko codes are already established as a format, so you could just use Gecko Codes as the coding language/format and manage the DOL space from there). Instead of the DOL mods being hard coded into the program, you could just include a bunch of mod files included with the program. This way, anybody can come up with their own file and distribute it, saying you can just put the mod file into the correct directory and the program would just be able to use it. That way people don't have to wait for updates and they can also put in any arbitrary mod that they personally prefer that's not included in the program.

That being said, one of the nice things I like about developing with Gecko is that I don't need to calculate branching; the gecko code will just handle the branch calculations itself. It looks like your program should be able to calculate the branch stuff as well, like the Gecko codes do. I also like the idea of being able to see how much DOL space is left, and it being built in that you can change settings how you like.

I can't speak for others, but the two main dol mods I've been dealing with are straight up command replacements (like instead of "addi r1, r2, 0x3" it's replaced by "addi r1, r2, 0x9" by overwriting that word in the DOL; the gecko codes would start with 04) and the mod where you branch from a location in the codebase to a location in the code cave/free space that has a bunch of other code (the gecko codes start with C2). There's one other one I was thinking of, and that's the C2 type of DOL mod except it also allocates part of the space in the "code cave" as global variables (I haven't needed these yet, but I've been thinking of doing this method). In ASM, the addresses to globals need to be hard coded, so it would be a little tricky getting these sorts of DOL mods to work (I have a workaround where you bl to a line to get the address of that line and then branch back and then read the link register, but that's super duper hacky and it takes up about four extra instructions, or 0x10 bytes, to do).
The other DOL mod that will be tricky is the ones where DOL mods need to call each other. For example, I want to change the debug menu, but the debug menu calls functions, and the debug menu needs to know where those functions live. If the DOL mod injection program places the mods automatically, we won't know where that function lives and we can't code the debug menu due to that.

I do like the idea of what your program promises and I'll try and take a look when I can. Since I've already started modding my Start.dol without your program, though, I've not wanted to start over quite yet.

 

[DRGN]

I still haven't had much of a chance to mess with your program, but I like the idea, just as a response to something you said:

While including it in the program is nice, I personally think it's more elegant of a solution to have a plugin or extension-like system where each DOL mod is its own file, which holds some sort of data (Gecko codes are already established as a format, so you could just use Gecko Codes as the coding language/format and manage the DOL space from there). Instead of the DOL mods being hard coded into the program, you could just include a bunch of mod files included with the program. This way, anybody can come up with their own file and distribute it, saying you can just put the mod file into the correct directory and the program would just be able to use it. That way people don't have to wait for updates and they can also put in any arbitrary mod that they personally prefer that's not included in the program.

Well, that's exactly how it's designed actually. I probably wasn't clear, but basically the library is a text file based system that the user can edit (so like you said, you don't have to wait for updates). The program will read however many .txt files there are in a folder called "Mods" and include all mods it finds in these in the program. Personally I have my mods divided into two files, one for static overwrites, and one for injection mods. But this is just personal preference and is totally up to the user. Each mod can be in its own file, like you said, each as a sort of plug-in or extension.

Having the code in Gecko form is more difficult because they would need to be converted. I thought about creating a converter, but I haven't looked a lot into it, so I don't even know all of the different types (C2, 04, etc) or whether it's even possible to convert all kinds of Gecko codes. If I can I'd like to create one in the future though.

That being said, one of the nice things I like about developing with Gecko is that I don't need to calculate branching; the gecko code will just handle the branch calculations itself. It looks like your program should be able to calculate the branch stuff as well, like the Gecko codes do. I also like the idea of being able to see how much DOL space is left, and it being built in that you can change settings how you like.

I can't speak for others, but the two main dol mods I've been dealing with are straight up command replacements (like instead of "addi r1, r2, 0x3" it's replaced by "addi r1, r2, 0x9" by overwriting that word in the DOL; the gecko codes would start with 04) and the mod where you branch from a location in the codebase to a location in the code cave/free space that has a bunch of other code (the gecko codes start with C2). There's one other one I was thinking of, and that's the C2 type of DOL mod except it also allocates part of the space in the "code cave" as global variables (I haven't needed these yet, but I've been thinking of doing this method). In ASM, the addresses to globals need to be hard coded, so it would be a little tricky getting these sorts of DOL mods to work (I have a workaround where you bl to a line to get the address of that line and then branch back and then read the link register, but that's super duper hacky and it takes up about four extra instructions, or 0x10 bytes, to do).

I know about the first kind you mentioned (which I call Static Overwrites in my program), and the second kind (called Injection Mods) where you branch to a custom function and then branch back. As for the global variables, these are an example of the arbitrary/standalone ASM you mentioned before, right? I'm having ideas of how I could incorporate support for it if I understand what you're saying. But I think I need to understand a bit more. Do you have an example?

The other DOL mod that will be tricky is the ones where DOL mods need to call each other. For example, I want to change the debug menu, but the debug menu calls functions, and the debug menu needs to know where those functions live. If the DOL mod injection program places the mods automatically, we won't know where that function lives and we can't code the debug menu due to that.

Not necessarily; I think we could still do that fairly simply. Just instead of writing a branch in your function, you would write a keyword or key variable (i.e. a short name that identifies your function). The functions would then also have these names. So when the program writes the functions into the DOL, it would read these identifiers and remember where it stores each function, and use/substitute that location when it comes to the identifier you put in the other function. So again, the program would handle the branching, and the user/writer just needs to know the ID of the function they want to branch to. This could be done with standard 48/4B branch commands. But I know there are other kinds of branches as well.... isn't there a kind of branch that already has this sort of "keyword branch" functionality built in? Like the "goto" command in batch scripting if you're familiar with that.

I do like the idea of what your program promises and I'll try and take a look when I can. Since I've already started modding my Start.dol without your program, though, I've not wanted to start over quite yet.

I totally understand not wanting to start over. Though the way the program is designed, you shouldn't need to, since it's designed to look at the game and autodetect whatever mods have already been added, regardless of whether they were initially added by the program or not. (Assuming they're in the library (which is really easy to update if they're not), and excluding the type of mods discussed above that I haven't added support for of course). Are you using mods other than static overwrites or injection mods atm?

The only thing to note is that when you hit save in the program, it will rearrange where the mods are stored in the DOL, in order to make the most of the space (by storing them end-to-end). You can open just your DOL, or your whole ISO into the program. But if you want to try it, I'd create a copy of your game just in case (or save a copy of your DOL, for which there is an export feature available if you opened your ISO).

 

[_glook]

I know about the first kind you mentioned (which I call Static Overwrites in my program), and the second kind (called Injection Mods) where you branch to a custom function and then branch back. As for the global variables, these are an example of the arbitrary/standalone ASM you mentioned before, right? I'm having ideas of how I could incorporate support for it if I understand what you're saying. But I think I need to understand a bit more. Do you have an example?

Let's say that you want turnip pulls to be on a roullette, so that instead of being random, it would just cycle through them. We need a spot in memory to store the last turnip pulled so we know what to pull next, and to also write what turnip was currently pulled when we pull it. The first thing we need to do is to create an Injection Mod, which branches from the place that determines which turnip is pulled. Translated to C++ code, it would look something like this:
int getNextTurnip() {
currentTurnip++;
if (currentTurnip > CONST_MAX_TURNIP) currentTurnip = 0;
return currentTurnip;
}
In the ASM code, "currentTurnip" would be hard coded. The address of currentTurnip also needs to be free space, which is the same space that the injection mods are placed in. If I'm just doing this by hand, I'd just make sure not to use the space I've mentally assigned to currentTurnip for anything else. I also know exactly what address I'm using as well, since it isn't automatically assigned. You can use the "variable name approach" you described, but instead of a branch, it would have to be for lis+ori combo.

Not necessarily; I think we could still do that fairly simply. Just instead of writing a branch in your function, you would write a keyword or key variable (i.e. a short name that identifies your function). The functions would then also have these names. So when the program writes the functions into the DOL, it would read these identifiers and remember where it stores each function, and use/substitute that location when it comes to the identifier you put in the other function. So again, the program would handle the branching, and the user/writer just needs to know the ID of the function they want to branch to. This could be done with standard 48/4B branch commands. But I know there are other kinds of branches as well.... isn't there a kind of branch that already has this sort of "keyword branch" functionality built in? Like the "goto" command in batch scripting if you're familiar with that.

No, there's no keyword branch in hex opcodes. When you go from assembly to hexcodes, the labels are translated into address differences, based on how far the label is away from the branch's address. The closest you could get is to something like that is create a data structure that holds a bunch of function's start addresses, retrieve one of those items in the data structure into a register, transfer that data to the link register via "mtlr", and then use "blr" to branch to it (or "blrl" if you want to treat it as a function call). The standard 48/4B branch expects an offset for a branch, not an id. If you wanted to implement this functionality in a text file, you'd probably have to change the format of how you do it. For example, here's what the format of an injection mod

Descriptiion of the injection mod
[Author of mod]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x001AD554 ---- 38600001 -> Branch

3C602802 60632D00
90640000 481AC7DC


   -==-

In order to get handled branching to work, you'd likely need another text file (along with Injection Codes and Static Overwrites), probably called "Standalone Functions". The format would likely be:

Description of function
[author of function]
<id_of_function>
3C602802 60632D00
90640000 481AC7DC
   -==-

You'd then need to support a new way to do the injection mod:

Descriptiion of the injection mod
[Author of mod]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x001AD554 ---- 38600001 -> Branch

3C602802 60632D00
call id_of_function
90640000
call id_of_another_function
481AC7DC 60000000


   -==-

The "call id_of_function" could possibly be called from inside a standalone function too:

Description of function
[author of function]
<id_of_function>
3C602802
call id_of_function
60632D00 90640000
481AC7DC
   -==-

This is the easier way of implementing it, but this means that any function or injection mod could call any standalone function, which means you don't know where it's branching from and where to branch back to. You still know where the function you're branching to to begin with, though, so you could stipulate that developers that write standalone functions should make sure they either don't change the link register or they do the proper saving of the link register themselves (via mflr and mtlr). The also need to handle their registers properly, and restore any register they used that isn't r0 or r3 through r10. In addition, the developer either needs to make sure to end the function in a blr or you need to end it in a blrl. The harder way of implementing it is finding all the references to id_of_function and making a putting the standalone function for every use of it, but this is inefficient spacewise if there is more than one reference to id_of_function and requires you to add another parse cycle of your text files. If you allow other standalone functions to call other standalone functions, you'd also have to do a double parse of the standalone functions text file.

I totally understand not wanting to start over. Though the way the program is designed, you shouldn't need to, since it's designed to look at the game and autodetect whatever mods have already been added, regardless of whether they were initially added by the program or not. (Assuming they're in the library (which is really easy to update if they're not), and excluding the type of mods discussed above that I haven't added support for of course). Are you using mods other than static overwrites or injection mods atm?

At the moment I'm not, so if it autodetect stuff, then that's super convenient, and I guess I can start using it already. It should make testing out experimental codes a lot easier.

 

[DRGN]

No, there's no keyword branch in hex opcodes. When you go from assembly to hexcodes, the labels are translated into address differences, based on how far the label is away from the branch's address. The closest you could get is to something like that is create a data structure that holds a bunch of function's start addresses, retrieve one of those items in the data structure into a register, transfer that data to the link register via "mtlr", and then use "blr" to branch to it (or "blrl" if you want to treat it as a function call). The standard 48/4B branch expects an offset for a branch, not an id.

Right. I understand that the 48/4B branches expect an offset. The ID I was referring to would be something going on in the program's code to identify what function is desired, which would then get the necessary offset and give that to the branch code.

If you wanted to implement this functionality in a text file, you'd probably have to change the format of how you do it. For example, here's what the format of an injection mod

Descriptiion of the injection mod
[Author of mod]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x001AD554 ---- 38600001 -> Branch

3C602802 60632D00
90640000 481AC7DC


   -==-

In order to get handled branching to work, you'd likely need another text file (along with Injection Codes and Static Overwrites), probably called "Standalone Functions". The format would likely be:

Description of function
[author of function]
<id_of_function>
3C602802 60632D00
90640000 481AC7DC
   -==-

You'd then need to support a new way to do the injection mod:

Descriptiion of the injection mod
[Author of mod]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x001AD554 ---- 38600001 -> Branch

3C602802 60632D00
call id_of_function
90640000
call id_of_another_function
481AC7DC 60000000


   -==-

The "call id_of_function" could possibly be called from inside a standalone function too:

Description of function
[author of function]
<id_of_function>
3C602802
call id_of_function
60632D00 90640000
481AC7DC
   -==-

This is the easier way of implementing it, but this means that any function or injection mod could call any standalone function, which means you don't know where it's branching from and where to branch back to. You still know where the function you're branching to to begin with, though, so you could stipulate that developers that write standalone functions should make sure they either don't change the link register or they do the proper saving of the link register themselves (via mflr and mtlr). The also need to handle their registers properly, and restore any register they used that isn't r0 or r3 through r10. In addition, the developer either needs to make sure to end the function in a blr or you need to end it in a blrl. The harder way of implementing it is finding all the references to id_of_function and making a putting the standalone function for every use of it, but this is inefficient spacewise if there is more than one reference to id_of_function and requires you to add another parse cycle of your text files. If you allow other standalone functions to call other standalone functions, you'd also have to do a double parse of the standalone functions text file.

Those format examples are actually really close to what I had in mind when I was talking about using "identifiers" with the functions and in the ASM. I would probably even use the "<" / ">" brackets since nothing else uses them. Plus, the code could be recognized as a standalone function simply by whether or not it has them. The functions could then be in their own file, or even mixed in with other mods of other types, if the user prefers it.

Is it a problem that the developer doesn't know where the functions are going to be if all they need to link them is the identifier? Either way, I could have the mod modules (the boxes in the program's lists for the mods, which display their titles, description, etc.) also display the offset for where the program will store them.

Even if the user doesn't know where the functions are stored, the program will, so I don't think I need to mess with any registers to handle branch returns; all of the branching could be added via 48/4B commands at the time that they're written to the DOL. (Is that what you meant about telling the developer to not change the link register, so that they could be used for branching back? Or are you talking about using the registers to essentially have the functions have return values?) So what I'm saying is that I think I can make it like the first scenario you described, in that any function could call any other function. There could even be an optional additional argument of branching to 'id_of_function' + an arbitrary offset, e.g. "call id_of_function + 0x8".

At the moment I'm not, so if it autodetect stuff, then that's super convenient, and I guess I can start using it already. It should make testing out experimental codes a lot easier.

Yeah, I'm hoping it makes both development as well as sharing easier. Not only does it make it super easy for anyone to add codes that others have made to their game, but it gets rid of the problem of one person's codes overwriting another because both codes used the same offset (and the implementer didn't check for it). This would otherwise happen more and more often as more and more codes are created and people's custom Melee becomes more complex with custom content. I was already tired of using a text file to keep track of my changes, and I didn't even have a whole lot in my own copy yet.

 

[_glook]

Even if the user doesn't know where the functions are stored, the program will, so I don't think I need to mess with any registers to handle branch returns; all of the branching could be added via 48/4B commands at the time that they're written to the DOL. (Is that what you meant about telling the developer to not change the link register, so that they could be used for branching back? Or are you talking about using the registers to essentially have the functions have return values?) So what I'm saying is that I think I can make it like the first scenario you described, in that any function could call any other function. There could even be an optional additional argument of branching to 'id_of_function' + an arbitrary offset, e.g. "call id_of_function + 0x8".

I'll give you an example. You have a standalone function with id "myStandStaloneFunction". You have two injection mods, both of which call "myStandStaloneFunction". Where does "myStandStaloneFunction" branch back to when it's injected into the DOL?

 

[Lucio08smash]

Can you install this on nintendont? sorry if this has been responded before

 

[divekicked]

Can you install this on nintendont? sorry if this has been responded before

Yes you can.

 

[DRGN]

I'll give you an example. You have a standalone function with id "myStandStaloneFunction". You have two injection mods, both of which call "myStandStaloneFunction". Where does "myStandStaloneFunction" branch back to when it's injected into the DOL?

Ohh, haha. I see, good point.

 

[_glook]

Can you install this on nintendont? sorry if this has been responded before

http://sdremix.com/installation/wii-installation/nintendont-method/

 

[sdremix_troubleshooter]

@ _glook Fantastic work on the SD Remix 1.02 port. Currently only Taunt Cancelling and Mewtwo's side-b mod are missing:

This is the original 1.00 inject code for side-b by standardtoaster

    @0x1000
    
    81DF0010 2C0E012F
    41820010 2C0E0130
    41820008 4082000C
    388000FB 48000008
    38800026 4808C520
    
    @0x8D120 - 38800026 -> 4BF73AC0

[11/9/2012 10:55:14 PM] Adam: you can try that out if you want
[11/9/2012 10:55:24 PM] Adam: makes foes go into missfoot after thrownmewtwo

 

[_glook]

@ _glook Fantastic work on the SD Remix 1.02 port. Currently only Taunt Cancelling and Mewtwo's side-b mod are missing:

This is the original 1.00 inject code for side-b by standardtoaster

    @0x1000
   
    81DF0010 2C0E012F
    41820010 2C0E0130
    41820008 4082000C
    388000FB 48000008
    38800026 4808C520
   
    @0x8D120 - 38800026 -> 4BF73AC0

[11/9/2012 10:55:14 PM] Adam: you can try that out if you want
[11/9/2012 10:55:24 PM] Adam: makes foes go into missfoot after thrownmewtwo

Thanks! I didn't even realize taunt cancelling was in. In that case, I assume I can just use the mod from the main mod thread:

Enable Taunt Cancelling (v1.02) [InternetExplorer]:
040DEE70 4BFA5411
040CA4CC 40820058

I'll try and mess around with the missfoot stuff, it should hopefully be a matter of moving the branch at 8D120 to 1E90 spaces away, in order to get the side+b tumble behavior.

 

[_glook]

I've attached two files.

SDR_Basic.zip contains the files I sent last time with Taunt Cancelling and Mewtwo's Side+B buff.

SDR_With_Extras.zip contains the SDR_Basic stuff with additions that I personally found neat. This isn't really to push things on the project, but I do want to show off what can be done and it reflects the product that I personally find would be nice to be included. These additions are:

• The following additional DOL mods:
  • Every player can control the debug menu
  • Tags can be 8 characters and lower case can be togged with X
  • Name tag no longer resets on port close and CSS exit
  • Hold A+B for salty runback
  • Unlock score display
• MODE TEAM TEST in the debug menu is replaced with EXTRA OPTIONS. It opens up a new menu with a bunch of toggles, which are:
  • Widescreen: Enabled or Disabled
  • Below Options: This option is a little complicated, but essentially it says how the rest of the options are applied.
    • Disabled: None of the options are applied, making the gameplay no different than normal SD Remix. In order to differentiate this state, the "Ready To Fight" banner at the CSS is normal colored (yellow).
    • Enabled: All of the rest of the settings are applied, allowing the player to customize their gameplay experience. In order to differentiate this state, the "Ready To Fight" banner at the CSS is green.
    • Melee+: Applies a preset of the options what I feel are User Experience and Gameplay enhancements. I'll point them out on each of the options below. In order to differentiate this state, the "Ready to Fight" banner at the CSS is magenta.
  • Handicap: Damage Ratio or Stock/Crew. If set to Damage Ratio, the Handicap setting behaves as normal. If set to Stock/Crew, it acts like stock control (Jorgasm's stock control mod). Melee+ uses "Stock/Crew".
  • Tap Jump: Sets it to enabled or disabled. Melee+ uses disabled, but now that I've tested it out, I don't know if I like it, as it makes running up-smash and running up-throw more difficult, as well as double lasers.
  • Always Rain Bombs: Can be set to Disabled, Enabled, and Pokeballs. If disabled, it does the normal bomb rain behavior. If enabled, bomb rain happens all the time. If set to Pokeballs, bomb rain happens all the time, and additionally, the bob ombs are replaced by pokeballs. Melee+ uses "Disabled".
  • Ledge Invincibility: Can be "Normal" and "Dynamic". If normal, ledge invincibility behaves like it always does. If set to Dynamic, ledge invincibility acts like a shield, where each time you grab the ledge, it reduces the invincibility time for the next ledge grab, but the invincibility recovers over time. Melee+ uses "Dynamic" (though it should be noted that while testing it just now, it seems to be buggy on Yoshi's Story for whatever reason).
    
  • Wall Bracing: Can be "Disabled" or "Enabled". If disabled, nothing is changed from normal gameplay. If set to enabled, if a character is going into a wall or being pushed into a wall and then is hit, that player can press away or toward the wall to "brace" against it, kinda like crouch cancelling. The main purpose of this is to help deal with wall infinites. Melee+ uses "Enabled".
  • Tiebreaking: Can be "Normal" or "Tournament". If normal, nothing is changed about the tiebreaking behavior. If set to "Tournament", if players/teams have the same stock/point/coin count, the player/team with the lowest total percent wins. If they are tied by percentage, a 3 minute, 1 stock match is played during sudden death mode. Bomb rain is disabled during Tournament sudden death, and the percentage starts at 0% instead of 300%. If time runs out, this match is also decided by percentage. If still tied, another 3 minute, 1 stock match is played. Melee+ uses "Tournament".

It took a while but this was a lot of fun to do. There's some other stuff I wanted to add, but I either didn't know how to do it or didn't get around to it:

• Nametags disappear during Zelda/Sheik/Mewtwo teleport up+B (I don't know how to do this)
• Start button actions disabled when holding X+Y (to help with joystick recalibration, I don't know how to do this)
• Pressing Start on match results screen doesn't undo your ready state (remapped to B, I don't know how to do this)
• Capped/Tennis mode (didn't get around to it)
• Taunt Battle (incompatible with Taunt Cancelling)
• Access Rumble Menu from CSS (I'm not sure where this DOL mod is)

It might be nice to edit shield colors too, I dunno.

Just to be clear to everyone, the SDR_With_Extras.zip is not indicative of an official release associated with SD Remix. It's just something I really wanted to do, and it's something I like playing myself. There should be no expectations that the actual SD Remix release will look anything like that.

Edit: You know when sometimes you send an email and forget to attach your files? Yeah.

 

[♡ⓛⓞⓥⓔ♡]

When 3.2 gets released, can we get it on the front page of SmashBoards?

I would PM SmashCaps and ask him. It would have to be settled before the update.

 

[Quillion]

Is it not possible to correct the programming error that results in Confusion being unable to hit with reflected projectiles?

 

[flieskiller]

Is it not possible to correct the programming error that results in Confusion being unable to hit with reflected projectiles?

iirc, if you confusion a projectile that has being confused, it becomes active again. Maybe it swaps to the wrong team (like passive neutral) then it swaps back to one of the players at the second confusion.

 

[sdremix_troubleshooter]

@ _glook I cannot thank you enough for what you've done for SD Remix. I will carefully consider the extras you included, as well.

 

[Quillion]

iirc, if you confusion a projectile that has being confused, it becomes active again. Maybe it swaps to the wrong team (like passive neutral) then it swaps back to one of the players at the second confusion.

So is it a simple matter of coding that can be fixed? SD Remix should fix it considering that Smash 4 already did.

Another thing @ _glook , have you gotten all the alt music unlocked in SDR 3.2?

 

[_glook]

So is it a simple matter of coding that can be fixed? SD Remix should fix it considering that Smash 4 already did.

Another thing @ _glook , have you gotten all the alt music unlocked in SDR 3.2?

No, I haven't.

 

[404House]

I'd like to thank you guys for the amazing work on this, I'm currently trying to make an SD Remix community in my area, and soon to have tourneys.

You guys are awesome.

 

[_glook]

Just so people know, at the very least, the Pl*.dat file for at least player 1 (and potentially for other files other than character files) is being written to usable memory using code 80085AE0. From what I can tell, this copies the entire file into memory. The function 80068E98 is called for every player, even if they picked the same character. It uses data that is stored at the memory location written to by 80085AE0. The start location for the Pl*.dat file loaded for Player 1 always seems to be 811ad5a0. When I tried doing it for player 2, it was C5EBC further away (I was still loading Player 1, though).

I would try to do a test to see if I can load SDR Bowser on a stock v1.02 ISO using only gecko codes, but the Pl*.dat file is a whopping 2FD00 bytes, and while I could make that Gecko code, no way Gecko is going to manage to fit that into memory. I'll probably try to make a custom diff of the files and see if that will fit in the Gecko loader space.

 

[_glook]

The hitbox at the end of the flame works! In addition, forward smash deals massive shield damage!
However, Bowser's down air is hilariously broken.

Video:

Gecko codes:

Spoiler

If player 1 is Bowser, that Bowser will be SD Remix Bowser.
Not really tested that well.
Also, doesn't include FSM changes.
Also, doesn't include flame cancel.
Also, down air is super broken (1.02) [_glook]
C2068F24 0000000D
3D80811A 618CD5A0
3D60803F 616BC420
894B0000 554A402E
892B0001 7D4A4B78
7D8C5214 2C0A0000
894B0002 4082000C
2C0A0000 4182002C
396B0003 39200000
890B0000 990C0000
396B0001 398C0001
39290001 7C095000
4180FFE8 4BFFFFB4
387F0000 00000000
223fc420 364404CD
063fc420 00000441
3644043D 4CCCCD00
01038F5C 29000103
4CCCCD00 11039333
33000903 C374BC00
0C0240C0 00330380
0000000D 0190000B
01EC0006 02420300
53018000 0701C000
020241D0 00070100
0086010C 00570440
00000000 14013D00
DE010600 14062C09
B8050640 00040601
9020990C 92000104
0C010F04 00020303
40000056 02070800
09011300 03010700
0F011300 03010700
03010800 0101DC00
06030019 00000104
00200007 0003030C
076C0004 0219C800
01020F00 00030151
00600106 00A8022B
85000201 3C002303
00000000 01010002
04021540 00120215
40006301 0D001301
0D003301 0C001301
0C00D701 0C002301
0C009001 14000902
15800001 01200001
018C0046 01170002
01200001 01400015
013C0001 014007C7
02051300 02011000
0F020513 00020110
000F0205 13000201
10001801 10003201
10001301 10001301
10005B01 30001301
30002B01 30005C01
25000701 28003A01
1C000401 0F000E01
1C001301 1C000C01
20004A01 1C000401
0E000E01 1C000401
0E000E01 1C001401
20005601 1C000401
0D000E01 1C001301
1C000C01 20003201
1C001301 1C000401
07000701 25002301
0F000C03 0F0C2800
04010F00 0C030F0C
28001C01 0C000E01
20000401 0C000E01
20000C01 2E007301
19000301 C8000801
19000102 79070003
01190003 01C80008
01190001 01790018
01090007 01300007
0137006E 01E8000A
0217C000 03015100
0301E800 0A0217C0
00030151 001B0100
00010206 40000205
0640F704 7F000501
29000301 00000102
06400002 05064008
FC7F0005 0129003C
01230007 01280007
012B00A0 055A1904
73000001 0111000D
055A1904 73000001
0111000D 056E1904
73000001 0111000D
056E1904 73000001
0111002F 01210034
013F0033 010F0008
02131900 04012900
44011000 09029540
00030121 0004010F
00090295 40000301
21000401 0E000902
95400003 01210044
010F000E 01290004
010E0057 0112000E
01350020 02064C00
03010800 02021190
0003018C 00020600
44040000 00000206
9D00007F 402C0001
07881006 40000000
00010403 E8871B00
010B1311 8439072C
82081006 40000102
00000001 04019087
1B000106 13118439
07040002 02054000
02020008 0002011F
0008014C 00020200
08000202 2A5C0002
010000D8 02000000
06022087 0005010C
00040200 00000602
20870005 010C002F
01001182 02183800
12021194 0012020A
F0005202 1F400012
02189C00 120211F8
005403B4 96000086
029BC000 01021307
0FB60244 08000303
0249F800 02037F40
28000302 0404000E
01080002 020B2800
03020407 000E0128
00030203 EF000E01
44000403 024A2E00
02037F40 4C000202
012C0002 03040834
00020105 00010611
9425990D D3000302
8B040002 02014000
03010800 0202264C
00020201 2C000203
1507D000 02060514
FE702617 00010513
2080408B 009C0420
808C8B0C 0E010C00
02030B5F E0000202
15C9006E 0209E400
02010100 03021FE9
16220274 C0000000
00000000 00000000
e2000001 00000000

Edit: By the way, if anybody knows why the down air is behaving so erratically, like maybe SD Remix is making changes to other files in order to swap animations, I would be much appreciative of that intel.

 

[sdremix_troubleshooter]

@ _glook No other files were modified to swap animations, this may provide some useful insight: http://smashboards.com/threads/melee-hacks-and-you-updated-3-15-2015.247119/page-101#post-15136472

 

[_glook]

@ _glook No other files were modified to swap animations, this may provide some useful insight: http://smashboards.com/threads/melee-hacks-and-you-updated-3-15-2015.247119/page-101#post-15136472

I see. I tried running the code on a copy of SD Remix; if my code worked properly, then there should be no difference. Turns out the dair is similarly screwed up. It looks like there's some funkyness with how animation data is loaded from the Pl*.dat file. It looks like I need to go one level deeper and figure out where 80085AE0 is getting its data from. If I go back far enough, I should be able to get it working.

Edit: There are many places in the Pl*.dat file which refer to relative addresses. I'm doing a simple overwrite of these sections with my diff, so it's not working because what looks like 00012E70 in the player file is something like 811C0550, if the offset used was 811AD6E0. In other words, I need to update my differ to take into account these change.

Edit 2: Proof of concept works, I've got down air working as well. Will update code once I've got the bugs figured out.

 

[_glook]

This one works much better and is theoretically extendable to do every character. Unfortunately, only one patch file fits into Gecko; any more and Dolphin starts complaining up a storm. I heard that you can fit 50k into the memory card hack, though, so maybe this will work yet. I don't think every character's differences is bigger than Bowser's and we can fit 33 of Bowser's patches in 50kb anyway.

Bowser is changed to SDR Bowser (v1.2) [_glook]

Spoiler

$Patch File
223fc420 11111111
063fc420 00000608
11111111 11111111
00000000 00000000
00000000 00000000
00000000 00000070
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
0D910003 00570A3E
00428F5C 00266667
00040001 00133333
00020001 000374BC
00030001 FFC00000
000C0001 00333333
00030001 FFD00000
00020001 00020000
00010001 00090000
00140001 FFC00000
00010002 FFD00000
FFC40000 00010001
FFE00000 00210001
08000000 00150001
001C28F6 00050001
01000000 00360001
FFFFFFFF 00050007
032DB805 024E0000
00000190 1CB10C92
000C010F DC000003
3BFC0000 00150001
04B00000 00010002
00000002 00000002
00030004 00000002
00000001 FFFFFFFC
00C80000 00010007
D8028000 D813FEF8
00000002 02BC0000
000003E8 FFF88000
00005000 00170001
00000002 002A0002
1C800000 23000000
00080002 D7FC4000
BA000000 00800001
00014000 00040001
00014000 00180001
00000C00 00040001
00000C00 000C0001
00000C00 00040001
00000C00 00350001
00000C00 00080001
00000C00 00230001
FFFFFFFF 00020002
00038000 0A007800
00110002 00050000
0A002C00 00050001
1E002C00 01F10002
00000280 00001000
00030002 00000280
00001000 00030002
00000280 00001000
00050001 FFFFFFFB
000C0001 00001000
00040001 00001000
00040001 00001000
00160001 00002C00
00040001 00002C00
000A0001 00002C00
00160001 FFFFFFF0
00010001 FFFFFFF0
000E0002 00001C00
00000002 00030001
00001C00 00040001
00001C00 00020001
FFFFFFFB 00120002
00001C00 00000002
00030002 00001C00
00000001 00030001
00001C00 00040001
FFFFFFFB 00150002
00001C00 00000002
00030001 00001C00
00040001 00001C00
00020001 FFFFFFFB
000C0001 00001C00
00040002 00001C00
00000003 00010001
FFFFFFF3 00080001
00000002 00030002
07802800 00000002
00030001 07802800
00060001 00000002
00030002 00002000
00000002 00030001
00002000 00020001
FFFFFFF7 001C0002
00000001 000000C8
00020003 0A0077E4
00000001 000000C8
00020001 0A007800
00050001 00000004
00010001 FFFFFFF3
00010001 FFFFFFF5
001B0001 0000E000
00020003 00024000
00005000 0000E000
00020002 00024000
00005000 0006000A
FFFFF800 01900000
F9BFFAEC 5A000000
00002800 FFFFF800
01900000 F9C00514
5A000000 00002800
000E0001 00000004
00010001 FFFFFFFD
00010001 FFFFFFF6
00280002 0F0C8460
EC001000 00030002
0F0C8460 EC001000
00030002 0F0C8460
EC001000 00030002
0F0C8460 EC001000
000B0001 00002000
000C0001 FFFFFFFB
000C0001 00000002
00020002 5E850000
00002800 00100001
00000002 00020003
00014000 00002000
00000003 00020003
00014000 00002000
00000003 00020002
00014000 00002000
00100001 00000002
00030002 00002800
00000003 00150001
00000001 00030001
00003400 00070015
FFFFFFF8 D0000000
78000011 04000000
3FFFFFFF 9803DFE5
F4000094 BBFC7F40
2C008773 063F80C0
D3FF13E5 7DBB0013
11843907 046906BD
0633FFF1 FC00018E
471B0013 0D843906
F4000005 37FFFFCE
8C00001F 00020003
43FFFFBA BC00002A
53FFFFB2 00360001
F8300000 00010002
16800000 FFFFFFFD
00010001 F8300000
00010002 16800000
FFFFFFFD 000B0001
FFFFFFFF 04600001
00000320 00040001
00000320 00040001
00000320 00140001
00000640 00040001
00000640 00040001
00000640 00150001
9E098000 00210002
000F4000 F5050000
03ED0005 44080000
000249F8 00007F40
28000000 04040000
00030003 0800000B
28000000 04070000
00030002 28000000
03EF0000 00030012
44000000 00024A2E
00007F40 4C000001
2C000004 08340000
05001194 25990DD3
0000008B 04000001
40000000 08000026
4C000001 2C000015
07D00000 0514FE70
26170013 2080408B
00270001 20808C8B
03030003 00000300
0004E980 FFFFDF50
001B0003 FFFFFF70
FFFFBD00 FFFFF87B
05880001 000035C8
00000000 00000000
e2000001 00000000
$Patcher
C2068F24 00000014
819D0000 558C103A
3D60803F 616BC428
7D4B60AE 2C0A0000
40820080 7D4B602E
2C0A0000 41820074
39200001 7D2B61AE
7D6B5214 3D408045
614A98B8 7D4A602E
814A0000 398AC9BC
A14B0000 554A103A
7D8C5214 2C0A0000
A14B0002 4082000C
2C0A0000 41820034
39200000 396B0004
810C0000 80EB0000
7CE83A14 90EC0000
396B0004 398C0004
39290001 7C095000
4180FFE0 4BFFFFB4
387F0000 00000000
C21A40B4 00000006
3C80803F 6084C428
38600000 38000000
98040000 38840004
38630001 2C030008
4180FFF0 3B3B000C
60000000 00000000

 

[_glook]

Okay, I know what most of the files are in the SDR source files using this: https://docs.google.com/document/d/1Q9uY3b9Xd-aUGHVsCLvLc6zR11-5DCPSHBSXb6mAjA8/edit#

However, there are some notable missing files. In particular, what do these files do?
GmTtAll.usd
All files with the name PlKbCp*.dat I see that they're Kirby's copy files. Fun.

 

[Doq]

GmTtAll.usd

Title Screen

 

[_glook]

@ Doq Thanks!

So I've been messing with memory card stuff, and I've managed to come up with something. I've tested this on console and it is incredibly buggy, but here's some of the stuff I've tested with this memory card save:

• Bowser seems to work flawlessly, and is the one cool thing with this hack.
  
• The FSM seems to work, at least for Bowser.
• Flame cancel works, and probably other DOL Mods.
  
• Mario is really buggy. His FSmash has an electric element apparently and eventually he just starts spazzing out.
• Falco and Fox seem to work fine.
• Trying to change your rumble settings crashes the game.
• Falcon's side+b buff dol mod works, but I can't tell if anything else has. Down B hasn't changed.
  
• Most other characters I tested seem to crash the game outright. There's probably something wrong with their patch files, and I'm going to have to deal with them on a case by case basis, like I did with Bowser.

As with most Memory Card exploits, you go to Name Entry to activate it. I haven't tried it, but I'm pretty sure entering a name is going to crash the game.

My hope is that this is the starting point for creating an SD Remix Lite version that can be distributed on memory cards.

This attempts to overwrite all the characters (though it seems to be doing it rather poorly as of now except for the case of Bowser), but there are several things that I've not even attempted with this:

• Stage changes
• PlCo.dat changes
• Menu changes
• Kirby's changes that reside in character files (DOL mods are easy enough and have been attempted to be included)

Maybe some of these can be tackled in the future, but not for now anyway.

Edit: I figured out that I'm using the wrong offset for the majority of the cast. Bowser works well because he's the only one that uses that particular offset. I'll just have to find the read file memory location and it should start working for the rest of the cast.

 

[_glook]

Hehehehehehehehehehehehehe:

All the characters should work now. It still doesn't have the stuff I mentioned in the last post though. But I'm sure someone will figure that stuff out, but I think I'm gonna take a break for a while.

Edit: Oh, and a link to the save file: http://www.mediafire.com/download/kym69w3i7n9s07m/SD_Remix_Extra_lite.gci