If you have kids or other people who play your Switch, and want it to work normally for them (the Album opening normally if they aren't holding the key combination) and not have them accidentally stumble into HBL, but also want them to be able to play with mods.
What's your proposal for controlling content overriding for fs.mitm?
My view is kind of that if you want to have mods on a title, you shouldn't be mitm-ing that title with HBL, but I'm prepared to hear a persuasive argument.
Could be as simple as atmosphere/titles/0100whatever/config.ini specifying a button combo to use for this title?
I'm not sure I'm understanding correctly. I have the Album overridden with HBL, and Zelda overridden with some modified game files. Both work fine, I just want to have one enabled by holding R and the other enabled without holding R. It's the easiest way to use mods that I know of.
Storing that data in an INI isn't really viable, because at check time calls to FS cannot be made. Any solution will necessarily be global.
But then I don't really understand? If HBL isn't overriding zelda, why does it matter that it shares a key combination?
Well, that's the point. The key combination is global, and I wish it weren't.
Could the INIs not be read at startup?
Right, but, why do you not want it to be global? I prefer a global solution on simplicity grounds.
INIs could theoretically be read at startup. However, I have another point to make:
The key used for HBL override is also the key used for loader overrides in general. That is, that key controls whether or not loader will apply code mods, as opposed to the data mods that fs.mitm applies. Having code mods and data mods be controlled by separate keys seems to me very highly undesirable...
Like I said in the first comment, I want the games to load with mods without any key combo, but require a key combo for HBL so that people don't open it by accident.
Right, the point I'm making is that the key combination used for HBL is the key combination used to control all executable mods -- it is a single "override executable content vs do not" combination for loader; I don't intend to change loader's behavior in any way that puts it at risk of memory exhaustion, and loader has a very low memory footprint.
You're telling me what you want, please justify the requested changes with what I've said in mind.
This is supported as of latest commit (6cc69fb).
Most helpful comment
This is supported as of latest commit (6cc69fb).