ROM Hack [Release] Sm4shCommand

  • Thread starter Thread starter Sammi Husky
  • Start date Start date
  • Views Views 276,850
  • Replies Replies 1,560
  • Likes Likes 25
KK, will do. Never heard of BBM, is there a preferred version out there I should be using? Most of the downloads I can find are 6 months to a year old. Also just to confirm again I went and removed the "Extra Data" that Smash had, I hope that was what I needed to do lol. There isn't anything else I need to do to make sure it's deleted?
 
KK, will do. Never heard of BBM, is there a preferred version out there I should be using? Most of the downloads I can find are 6 months to a year old. Also just to confirm again I went and removed the "Extra Data" that Smash had, I hope that was what I needed to do lol. There isn't anything else I need to do to make sure it's deleted?
under the program tab in bbm delete ctr-u-axce then install the update from the sdmc tab. BBM is a pretty old tool. I dont think it gets updated often.
 
Hm, I launched Smash after installing through BBM and I just get a black screen. Not sure what to do at this point... I made the edits to code.bin using my own script, so I could've messed up there, but I honestly don't know.
 
Hm, I launched Smash after installing through BBM and I just get a black screen. Not sure what to do at this point... I made the edits to code.bin using my own script, so I could've messed up there, but I honestly don't know.
It should be black. For a while.
 
I'm having trouble rebuilding the dt and ls files, I'm entering in the right command. This is the error
ZLib error -3: Data was corrupted (incorrect header check)

Unhandled Exception: ZLibNet.ZLibException: ZLib error -3: Data was corrupted (i
ncorrect header check)
at ZLibNet.DeflateStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at ZLibNet.StreamHelper.InternalCopyTo(Stream src, Stream destination, Int32
bufferSize)
at ZLibNet.StreamHelper.CopyTo(Stream stream, Stream destination)
at ZLibNet.CommonCompressor.DeCompress(CreateStreamDelegate sc, Stream source
, Stream dest)
at ZLibNet.CommonCompressor.DeCompress(CreateStreamDelegate sc, Stream source
)
at ZLibNet.CommonCompressor.DeCompress(CreateStreamDelegate sc, Byte[] source
)
at ZLibNet.ZLibCompressor.DeCompress(Byte[] source)
at DTLS.RFFile..ctor(String filename)
at DTLS.Program.PatchArchive(String resourceString, String patchFolder)
at DTLS.Program.Main(String[] args)
(My files are the same size as original)
 
Last edited by Manito,
Yeah, my .cia did not work. Here's the source of my script I used to patch this. Anyone see any mistakes in outright, like in my insertion points?

...I hope some brave soul will be willing to post their build on that site soon, troubleshooting this is getting tiring lol.
 
Yeah, my .cia did not work. Here's the source of my script I used to patch this. Anyone see any mistakes in outright, like in my insertion points?

...I hope some brave soul will be willing to post their build on that site soon, troubleshooting this is getting tiring lol.
Code:
    "hookdatasize" : 0x13F4B8,
    "datasize"     : 0xA1C800,
    "hooklock"     : 0x1816CC,
    "lock"         : 0xA1B800,
    "hookexist"    : 0x159E9C,
    "exist"        : 0xA1CD00,
    "hookfind"     : 0x16EFAC,
    "find"         : 0xA1CF00,
    "sdsound"      : 0xA1CB00
These are off by 0x100000 you need to lower each one. (Im not sure if you did this somewhere else in the script) so A1C800 should be 91C800
 
I do, check a little below. I run my script with the -0x100000 to be tacked on always (though if you don't run it with -codebin it does not do this).
 
I do, check a little below. I run my script with the -0x100000 to be tacked on always (though if you don't run it with -codebin it does not do this).
I sent you a pm with my code.bin that I made manually. Maybe you can figure out what you did wrong with that.
 
Thanks a ton, though I just found a huge crucial bug in my code. I did write() to write the bytes instead of rawWrite() so the File wrapper thought it needed to convert my array into a string and print it to the file... Which is obviously not what I wanted to do!

Here's the source (source in download) as is, going to test it now.

EDIT: It works!!! Though it crashes on quitting a match... Is this known, or my fault?

EDIT2: Added a binary since I know it works now. Note that you should probably be running this with:

Code:
SaltySDPatcher.exe code.bin -codebin

This will grab the newest files off of GitHub, compiling them with the Makefile (thus you need DevkitPro), and patching the ROM. The -codebin flag makes sure the addresses are put 0x100000 bytes back from where shinyquagsire specified his addresses, which is necessary for patching code.bin files.

If you have the bin files already in some folder, you can do:

Code:
SaltySDPatcher.exe code.bin some/folder/path -codebin

...which will just skip the downloading and use the ones you provide.

EDIT3: Fixed major bug, disabled find hooks.

EDIT4: Didn't realize Window corrupted the .zip file... The .exe is fine, but the source file is broken. I'm going to put the source on GitHub in a few hours, so whatever...
 

Attachments

Last edited by TheGag96,
Just so everyone knows, I just found out that my find and findf hooks are literally useless because apparently they're passed just a filename (ie someimg.tex vs /ui/something/someimg.tex), so what ends up happening is it just always fails and defaults to the main code, slowing things down with the file checks. So in the current build you can just not insert and hook findf and find and you'll basically be fine.

Also, I just finished a basic crc store version of SaltySD, the upside is that files load a lot faster, the downside is that you're tethered to a python script on your PC, and you have to run it every time you add new files. Basically it generates a list of crc values of every SD file, and then on the hook side it'll crc each file that's about to be loaded, compare that crc to every crc in the store, and if it finds the value in the store it will proceed to SD override. For users this isn't actually that much of a bother, but for people testing it might be annoying. Would it be better to release this now, or try to get the crc cache generator put into Sm4sh itself without even bothering for a partial release? The other issue is launch methods, I'd like something better that doesn't require illegally downloading a patched update CIA or patching it on your own, but HANS doesn't support updates. If I did do a launcher, I could move crc cache generation in there, which might be a bit easier.

I suppose a hybrid between the two would be having a patched update cia and then making a program which does the crc store and then launches Sm4sh, but that would be too much of a workaround imo.
 
Last edited by shinyquagsire23,
  • Like
Reactions: I pwned U!
Just so everyone knows, I just found out that my find and findf hooks are literally useless because apparently they're passed just a filename (ie someimg.tex vs /ui/something/someimg.tex), so what ends up happening is it just always fails and defaults to the main code, slowing things down with the file checks. So in the current build you can just not insert and hook findf and find and you'll basically be fine.

Also, I just finished a basic crc store version of SaltySD, the upside is that files load a lot faster, the downside is that you're tethered to a python script on your PC, and you have to run it every time you add new files. Basically it generates a list of crc values of every SD file, and then on the hook side it'll crc each file that's about to be loaded, compare that crc to every crc in the store, and if it finds the value in the store it will proceed to SD override. For users this isn't actually that much of a bother, but for people testing it might be annoying. Would it be better to release this now, or try to get the crc cache generator put into Sm4sh itself without even bothering for a partial release? The other issue is launch methods, I'd like something better that doesn't require illegally downloading a patched update CIA or patching it on your own, but HANS doesn't support updates. If I did do a launcher, I could move crc cache generation in there, which might be a bit easier.
Two things.
1. I think you should release both versions when completed, one that has the crc store version, and one without.
2. Either an NTR Patch or launcher should be sufficient. (especially if it doesn't require CIA, if it does that's fine as we all already use CIAs to install the modified updates with SaltySD.)

Either way I love the current progress and can't wait to see more!
 
Just so everyone knows, I just found out that my find and findf hooks are literally useless because apparently they're passed just a filename (ie someimg.tex vs /ui/something/someimg.tex), so what ends up happening is it just always fails and defaults to the main code, slowing things down with the file checks. So in the current build you can just not insert and hook findf and find and you'll basically be fine.

Also, I just finished a basic crc store version of SaltySD, the upside is that files load a lot faster, the downside is that you're tethered to a python script on your PC, and you have to run it every time you add new files. Basically it generates a list of crc values of every SD file, and then on the hook side it'll crc each file that's about to be loaded, compare that crc to every crc in the store, and if it finds the value in the store it will proceed to SD override. For users this isn't actually that much of a bother, but for people testing it might be annoying. Would it be better to release this now, or try to get the crc cache generator put into Sm4sh itself without even bothering for a partial release? The other issue is launch methods, I'd like something better that doesn't require illegally downloading a patched update CIA or patching it on your own, but HANS doesn't support updates. If I did do a launcher, I could move crc cache generation in there, which might be a bit easier.
I wouldnt rely on hans too much, because it will most likely never have support for smash on 3ds. As for when you release it, I think you should hold off a bit until you have it perfected. Salty Sd alone is enough to keep us busy for a while. I wouldnt mind a launcher, that would be pretty neato, this way we dont have to keep uninstalling and reinstalling updates whenever we want to play online. Also, how would the python on the computer work? Would it just generate a file that we place on the sd card each time we want to add another path to get overridden to the sd card?
 
I wouldnt rely on hans too much, because it will most likely never have support for smash on 3ds. As for when you release it, I think you should hold off a bit until you have it perfected. Salty Sd alone is enough to keep us busy for a while. I wouldnt mind a launcher, that would be pretty neato, this way we dont have to keep uninstalling and reinstalling updates whenever we want to play online. Also, how would the python on the computer work? Would it just generate a file that we place on the sd card each time we want to add another path to get overridden to the sd card?
Basically that, you point the script to your sdmc:/saltysd/smash/ folder and then it generates a cache.bin, which you place at sdmc:/saltysd/smash/cache.bin. It's pretty simple, just annoying to do. I feel like having a separate launcher might be the way to go now that you mention online, because there will definitely be those who mod their games a lot more than others to the point where online is no longer compatible.
 
Thanks a ton, though I just found a huge crucial bug in my code. I did write() to write the bytes instead of rawWrite() so the File wrapper thought it needed to convert my array into a string and print it to the file... Which is obviously not what I wanted to do!

Here's the source as is, going to test it now.

EDIT: It works!!! Though it crashes on quitting a match... Is this known, or my fault?
It might be your fault some how. I remember with an older version of salty sd if you straight up copied all the fighters from the update dt ls into /saltysd/smash it would crash after each match, but with the current set up it shouldnt be having those problems
 
It might be your fault some how. I remember with an older version of salty sd if you straight up copied all the fighters from the update dt ls into /saltysd/smash it would crash after each match, but with the current set up it shouldnt be having those problems

Not sure why that would be... I'm using the newest files.


Aw, now I gotta update my script again! :P (Seriously though, thanks for all of this!)
 
Because I doubt undubbed Smash 4 will ever gain incredible amounts of popularity -- much less have an entire community surround it with undying love for it in the way things like B-, B+ and PM did, or in the way singular character mods like Goku or Ridley did. People are currently far more invested in figuring out what new things can be done and what we can modify that matters in the long-run than what probably amounts to the simple swapping of a few files.
Maybe not many people would be interested but I challenge any of you on doing and undub and you will see its not easy, if it was easy then I'll not ask for help
 

Site & Scene News

Popular threads in this forum