Configurable key combo

[diwo]

Stores key combo in sdmc:/switch/.overlays/tesla.conf as json, e.g.

{
  "comboKeys": "L+DDOWN+RSTICK"
}

Resets the config to the original combo if file doesn't exist or syntax error.

Planning to implement a UI to update the combo in Tesla-Menu using KeyCombo::update and KeyCombo::KEYS_INFO.

[WerWolv]

I see three main issues with this. First one being nlohmann::json is gigantic. It takes ages to compile and kinda bloats the executable usually leaving even less space to devs. Second, this will cause a file to be opened and parsed every time a overlay gets started. I'm a bit worried that that's going to be slow or, even worse, corrupt the SD card on exFAT easily. Third, the current combo behaviour is that L + DDOWN unlocks the combo and RSTICK triggers it. I'm not concrete on that one but does your way feel natural to use? And is hard to activate it by accident?

[diwo]

Hmm, didn't realize executable size also counts against the limit resource available. There currently isn't a need for complex object representations so I guess hand-rolling an ini-style config format is an option.

Currently the mechanism relies on reading the file for different overlays to share the same configuration. The file is only loaded once when an overlay loads, and it seems "instantaneous" (at least with my SD card), but exFAT corruption would really suck though. The alternative would involve passing the keys through args in Tesla-Menu. It'll also restrict the combo to be set from it rather than to be able to set it from any overlay, which isn't a bad thing.

The new combo behavior triggers whenever a key which contributes to the combo joins in to "form a circuit". So, if you have all the required keys held down, you can release and press any of those keys to toggle the menu on and off. Pressing any other key while the required keys are held down has no effect.

The key detection mechanism seems sane to me. Let me see what I can do about the first 2 issues, though the second one may bit a little more involved.

[WerWolv]

When you take a look at the dev branch, I added two new options to the system_settings.ini file for the combo. I think the best way would be to have nx-ovlloader read that config and pass it through arguments to the Tesla-Menu which then continues to pass those values ahead to the next overlays. Instead of args, I also thought about overriding libnx's setup code to change the Homebrew ABI to include the new values and make it a "Overlay ABI". That might actually be the cleanest way to handle it

[diwo]

Looks like you already have a lot of work in progress in this area, I guess I'll just hold off on this change until you have something ready. Feel free to use any of the code from the PR if you like.

I was working on a UI to let users change their combo, but I was building it with the assumption that there wouldn't be a distinction between "trigger keys" and "unlock keys". I still think enforcing the ordering in which the buttons need to be pressed would confuse users. Typically people just press all of them down at the same time. With trigger key, the combo would "sometimes not work" unless they're aware of the mechanics beforehand.

Let me know what you think on trigger keys, I would have to change the UI workflow if you would rather keep it. Also let me know if there is anything you could use help with. Awesome work with this project!

[WerWolv]

Thinking about it, Rosalina, the overlay menu on the 3DS did the same really. As soon as you pressed L + DDOWN + Select it opened no matter what order. So if you already have a nice system working I'm in for that ^^

I'm not really attached to the current UI system. I tried to improve a bunch of things in the dev branch if you want to take a look at that. I tried to make it all header-only but ran into weird issues with font rendering that I couldn't figure out what caused them. If you have ideas for a better system for anything really, let me know!

[diwo]

Closing this since it's outdated