Each entry in the resource file is linked to a string within the resource file, and by iterating through them you can piece together a path. The RF header should be searchable in the DT file, but the data after the header is compressed.
ROM Hack [Release] Sm4shCommand
- Thread starter Sammi Husky
- Start date
- Views 245,355
- Replies 1,560
- Likes 25
Each entry in the resource file is linked to a string within the resource file, and by iterating through them you can piece together a path. The RF header should be searchable in the DT file, but the data after the header is compressed.
Ah, It's near the end of the DT file. I don't know how me or the hex editor missed that before ._.;
Thanks again, as always.
Thanks again, as always.
Made a really good amount of progress on dt/ls to SD redirection, I've gotten it to the point where files on the SD card will override existing resources, and will replace the existing data when loading. However, at the moment it is somewhat sluggish during loading screens, and files overridden from SD can only be the same size or smaller as the original file. It also only works on 1.1.3 at the moment, but it should be portable to other versions. I'm trying to work out how the data is allocated out so I can just replicate that allocation rather than go through the entire file loading procedure and then loading a file on top of it. But at this rate, I'll probably have SD redirection done within a few days, hopefully.
Failed attempt to texture mod:
EDIT: It also seems to crash on loading stages, so there might be more work to be done.
Failed attempt to texture mod:
EDIT: It also seems to crash on loading stages, so there might be more work to be done.
Last edited by shinyquagsire23,
I know a good few people who'd jump at the opportunity to screw around with that in it's current form, but a few days it is.
the prayfest continues
Yeah I'd rather just have it done 100% than releasing it as it is. So far I have it working with allocations, but I can't get it to deallocate. It just keeps allocating and allocating until the game inevitably crashes. Apparently (at least on N3DS) a TON of things are kept in RAM for a long time, so finding out where it deallocates these things is somewhat tricky.
If you don't mind me asking, and aren't too busy to answer, how exactly does what you're making 'work'? A change to the game itself, or to how it's run..
Basically, Resource objects have their data loaded on Resource::lock(bool), so I hooked that routine (and for now, only that, but I need to hook Resource:data_size() in the future). But rather than constantly reload commonly used resources, the engine will cache the loaded resources in RAM. I found out how the RAM offsets for storing these values are calculated, but how they are actually cached and deallocated I don't know. For some reason I can't seem to get my replaced resources in early enough from RAM patches, which is odd. It might just mean I need to hook elsewhere.
Well.. I'd have to say 'of course'. It's just that nobody's completely sure exactly how yet, as far as I know.
Parameters and such that haven't been figured out that we'd need to figure out how it detects the controller for moves like Fire Fox and applying it for a directional airdodge are a little bit out of the way.
Hi guys, I'm trying to make an undub version, and I was able to put the files of the Japanese version on the American version, but as you know the Japanese version has English language. My question is, Where or what is the file that tells the game the language of your 3DS?. Or how I can edit the voiced files? Any help would be greatly appreciated
Finished a first version of my dt/ls redirection, you can find the source and patching instructions at https://github.com/shinyquagsire23/SaltySD/tree/master/smash. Currently the addresses are for 1.1.3, so not sure if it'll work with HANS, but you can patch your own update CIA or patch it with NTR/similar if you want to give it a go. Currently it works and it doesn't leak memory, however loading screens take a long time and the character select screen has some nasty lag due to checking if files are on the SD card. I'll probably rework some of the redirection soon to get it more usable for the average user, however if you're experimenting with ACMD stuff or whatever, this works perfectly.
Cant wait to try it out. Is there any required libraries in order to compile it?
It only needs DevKitARM, and you have to be patching 1.1.3. It pulls most functionality from the game itself.
When you say patching 1.1.3 do you mean the code.bin for 1.1.3 and then rebuild the update, or use the code.bin for 1.1.3 and use that to rebuild the entire game? Also, if this is using the 1.1.3 code.bin should I use these as the offsets when replacing the values?
0x13F4B8 = 0x3F4B8
0xA1C800 = 0x91C800
0x1816CC = 0x816CC
0xA1B800 = 0x91B800
0x13F4B4 = 0x3F4B4
0x140DBC = 0x40DBC
I'd rebuild the 1.1.3 update with the code modifications. And yes, those would be the code.bin offsets you'd use. Make sure you check the Github every so often because I'm finding more and more issues with my initial release. The current one I'm fixing is that you still can't create and load files outside the normal list of files in dt/ls, which could be problematic for adding new things.
How do you rebuilt the update cia? The way I have rebuilt it so far was to rebuilt the game as a .3ds with 3dsbuilder and convert it to a .cia, but that doesnt work with game updates. Please help
I use this:
Code:
makerom -f cxi -target t -rsf gw_workaround.rsf -o smash-113t.cxi -exheader exheader.bin -code exefs/code.bin -romfs romfs.bin -icon exefs/icon.icn -banner exefs/banner.bnr -alignwr
Exinjector.exe -rom smash-113t.cxi -exheader exheader.bin -sd
makerom -f cia -target t -content smash-15t.cxi:0:0 -o smash-113t.ciaSimilar threads
