Hacking ROM Hack exeFS patches for Mario Odyssey crash on start. Mods with only romFS modifications do not crash.

[dev4hire]

Unfortunately I have had some rough starts trying to make modifications for Super Mario Odyssey. I also cannot post links as my account is too new, so I'll try to be descriptive.

To start, I'm on CFW 14.1.2 and Atmosphere 13.2 on emuMMC. SMO is on 1.0.0.

I started trying to build CraftyBoss's Gravity Mod, and spent time debugging why it would crash on my system. The next logical step is to try a more bare-bones example, such as the Starlight SMO Base project (and CraftyBoss's version) that warps Mario to coordinates 0,0 when pressing left d-pad. Of course, this failed too.

So I thought it was my build environment. I tried Ubuntu 20.04, the devkitpro docker image, and WSL. Same results.

I downloaded the prebuilt and ready to use patches from Game Banana. None worked. I tried several mods such as Superstar Mode, Mario Odyssey Online, etc. The only one that did work happened to be Floor is Lava mod, and I found it was because it was the only mod to only use romFS and not exeFS and exefs_patches.

So I looked more into the patches and made sure they match my build ID, and they do (3CA12DFAAF9C82DA064D1698DF79CDA1).

Does anyone know where to look from here? Am I missing something obvious? Every mod that requires exeFS modifications gives me a crash the moment the game opens. I believe this to be an issue with Atmosphere, but maybe not.

Thanks!

EDIT: Solved! See #10. TL;DR: Change FTP clients to transfer in binary mode. ASCII mode is on by default and it ruins the files.

 

[dev4hire]

Quick update, maybe this can help:

Removing or renaming the patch file and leaving the sdk1 file has the same result.

It's either failing because the patch isn't being applied, or because of the sdk1 file. Both are weird because I'm using a legitimate copy of SMO and a clean Atmosphere install with prebuilt and released mods.

 

[masagrator]

Quick update, maybe this can help:

Removing or renaming the patch file and leaving the sdk1 file has the same result.

It's either failing because the patch isn't being applied, or because of the sdk1 file. Both are weird because I'm using a legitimate copy of SMO and a clean Atmosphere install with prebuilt and released mods.

if you are putting subsdk file as part of mod, you need to be aware that it may hook function that your exefs patch is patching, causing conflict.
So issue is probably that those patches and exefs mod are incompatible with each other. Use just one exefs patch and delete any exefs and romfs mods. If it works, you have an answer.

 

[dev4hire]

if you are putting subsdk file as part of mod, you need to be aware that it may hook function that your exefs patch is patching, causing conflict.
So issue is probably that those patches and exefs mod are incompatible with each other. Use just one exefs patch and delete any exefs and romfs mods. If it works, you have an answer.

Thanks for the reply

If I'm understanding correctly, you're saying multiple patches would conflict with each other. However I am only running a single mod at a time, each with only 1 patch and 1 subsdk1 file.

 

[masagrator]

each with only 1 patch and 1 subsdk1 file.

If they are not a part of the same mod, they could still conflict with each other.

 

[dev4hire]

If they are not a part of the same mod, they could still conflict with each other.

They are part of the same mod. I've left no artifacts of the previous mod when trying another.

 

[masagrator]

They are part of the same mod. I've left no artifacts of the previous mod when trying another.

Try to leave just exefs patch and run again.
If it goes through, then that means your mod is incompatible with version you are using.
exefs patch is using filename as safety to not run on any other version. romfs mods don't have such safety and for exefs mods this must be implemented by dev itself (and usually isn't)

 

[masagrator]

Btw. you don't use SaltyNX, right?

 

[dev4hire]

Btw. you don't use SaltyNX, right?

I do not. I haven't heard of it until now.

Try to leave just exefs patch and run again.
If it goes through, then that means your mod is incompatible with version you are using.
exefs patch is using filename as safety to not run on any other version. romfs mods don't have such safety and for exefs mods this must be implemented by dev itself (and usually isn't)

After removing any trace of any mods, applying just one mod, and then removing the subsdk1 file and leaving only the patch file, it crashes. Not immediately. It hits the black Switch loading screen but fails after a second or two (the normal loading time) before the controls screen gets to load.

The build ID for the game (SMO 1.0.0 BID 3CA12DFAAF9C82DA064D1698DF79CDA1, retrieved from Edison) is the correct build ID the patch was named after when it was downloaded (3CA12DFAAF9C82DA064D1698DF79CDA1.ips). This is also the case for mods I've built from source, which I have tested with the same methods and isolated from any other mods.

 

[dev4hire]

UPDATE (SOLVED)

FileZilla was transferring in ASCII mode and not Binary mode across all OSes. FileZilla and other FTP clients like CyberDuck need to be set in binary mode, otherwise it ends each file with a new line character, which is invalid. I'm unsure why Ubuntu did this when I transferred via USB SD via Hetake or just writing directly to the SD card, but that was it and it's solved now.

Anyway, sorry for the specific issue, but hopefully this documents it well enough that it can be a reference to others facing the same.

EDIT:

If you're having trouble with any of source code of CraftyBoss's mods (or any mod from the Starlight SMO base repository), the Makefile does not move the `romfs` folder in the base of the project into the `starlight_patch_100/atmosphere/contents/0100000000010000/` folder. You will need to move that yourself, or add this to the end of the "starlight:" section of the Makefile

`cp -R romfs starlight_patch_100/atmosphere/contents/0100000000010000/`

 

[rodolfol]

Btw. you don't use SaltyNX, right?

It's salty a reason for exeFS patches to not work?

 

[masagrator]

It's salty a reason for exeFS patches to not work?

It can be a reason why subsdk mod doesn't work. It doesn't affect exefs patches.

 

[rodolfol]

It can be a reason why subsdk mod doesn't work. It doesn't affect exefs patches.

Oh thanks I was having a similar problem with another game but it was something else I managed to fix it

 

[dev4hire]

Oh thanks I was having a similar problem with another game but it was something else I managed to fix it

Do you mind describing the issue and how you solved it? I'd like to leave as many solutions here for mod issues as we can. There aren't many threads about it and the problems can be pretty obscure.