Changing selected title disables mods for other titles

[Michael Gosling]

Steps:

1. Start ModMoon
2. Use Y to select title
3. Change mod using selector at bottom
4. Press start to close ModMoon and apply changes
5. Start ModMoon
6. Use Y to select different title
7. Change mod using selector at bottom
8. Press start to close ModMoon and apply changes

Expected result: Both games have selected mods applied
Actual result: Only the last selected title has mods applied

Not sure if this is a bug or just a missing feature, but I use SimpleModManager on Switch and it's capable of applying mods for multiple titles. I understand the lack of multiple mod support because that could be difficult to track properly, but applying mods for multiple titles should be as simple as writing the slot to the corresponding luma/titles/<title_id> folder.

[Swiftloke]

Hi, thanks for the concise and well-written issue report!

This is a valid problem and it's definitely expected behavior. I gave it some thought, and fixing it might be easier than you'd think.

I see two problems:

• Utilize the shiftmodsin/out/shiftcodeipsin/out logic when a user picks a title in the title select menu.
• When a user deselects a mod from the active title select menu, check to see if they have a mod active. If so, shiftmodsout/shiftcodeipsout so that the mod isn't stuck as active.

Note that the shifting operation is pretty costly and might incur some lag upon a title switch. I experimented with this a lot back in 2017 with Smash Selector so that a user could close it at any time because the mods were always in the right place, but the 3DS' SD card operations are very slow in general (goes through FS sysmodule -> goes through arm9 + simply slow hardware across the board) and I had to scrap the idea because, IIRC, there ended up being a ~2s delay between every mod switch- and with an array-type selector like SS/MMs, that got unacceptable pretty quickly. This delay is probably still there today since the core logic hasn't changed much but it's very easy to hide it behind launching a game or exiting to the home menu.

That's probably why I never thought to implement this, because shifting mods during program operation is something that kind of should be avoided at all costs, but you're more than welcome to implement the above in a PR and we'll benchmark things to see how it goes. Maybe a "shifting queue" to ensure that mods for every modified title are shifted upon exit would be a superior approach. Let's discuss- assuming you're willing to help with the fix! :)

[Michael Gosling]

Thanks for the quick and detailed response. That makes a lot of sense, I hadn't considered that the SD Card operations were slow enough to lock the UI for that long. I think a queue that applies a series of changes on exit is a perfect solution. There might be some value in a setting/preference that allows for operations to be applied with a "save" or "apply" button, with a big warning about the impact on performance.

I haven't touched C++ in a long time (my job has me doing TypeScript mostly, C# sometimes) so I'm afraid I might be too rusty to help much here. But I'll find some time in the next few days to setup a dev environment and see if I have any hope at tackling it.

[Swiftloke]

C++ development environments with devkitARM are... less painful shall we say compared to most cross compilers. The fine folks at devkitPro (specifically WinterMute and fincs) make it a mostly one-click installation.

More good news for you is that the C++ in this project is fairly straightforward with none of the crazy stuff that comes with templates etc. - I was a much less experienced programmer when I wrote this project. You should be able to read it without much trouble.

[Michael Gosling]

C++ development environments with devkitARM are... less painful shall we say compared to most cross compilers. The fine folks at devkitPro (specifically WinterMute and fincs) make it a mostly one-click installation.

More good news for you is that the C++ in this project is fairly straightforward with none of the crazy stuff that comes with templates etc. - I was a much less experienced programmer when I wrote this project. You should be able to read it without much trouble.

trying to configure vscode to use the right intelligence and whatnot for this repo. Do you know which binary it uses for arm-none-eabi when compiling? if there's a specific cpp or c standard to use as well that might help.

I have this config right now but setting the intelliSenseMode and compiler to these values is giving me errors about stoi , among other things. I think the includes are correct, at least.

{
            "name": "Mac",
            "includePath": [
                "${workspaceFolder}/**",
                "/usr/local/include",
                "/opt/devkitpro/libctru/include",
                "/opt/devkitpro/devkitARM/arm-none-eabi/include"
            ],
            "defines": [],
            "macFrameworkPath": [
                "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks"
            ],
            "compilerPath": "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc",
            "cStandard": "c17",
            "cppStandard": "c++98",
            "intelliSenseMode": "macos-gcc-arm"
        }

[Michael Gosling]

this config seems to work, if anyone else stumbles across this and wants to use vscode.

.vscode/c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [
                "/usr/local/include",
                "${workspaceFolder}",
                "/opt/devkitpro/libctru/include",
                "/opt/devkitpro/devkitARM/arm-none-eabi/include",
                "/opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/11.1.0/include"
            ],
            "defines": [],
            "macFrameworkPath": [
                "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks"
            ],
            "compilerPath": "/usr/bin/clang",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 4
}