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

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

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

 

[_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