Implement controller profiles for emulated controllers and a few QOL options

[Banz99]

To do in the future: Use an actual stringifier for profiles values instead of copy pasting the default.

This should take care of #87, #43, and could lead to fixing #34 and #22.

[ndeadly]

general settings should probably be at the top of the file

[ndeadly]

either align all these or leave only a single space around the =

[impeeza]

Cool functions, I Wish to know ho to program at that level 8-D

[abjugard]

What is the status on merging this?

I have never been a friend of the Nintendo button layout, and the built-in remapping system is frustrating to use as it prompts every time I start if I actually want to keep the mappings I've made. Would rather just setup my Xbox Elite Series 2 controller with the Switch and have MissionControl keep A->physical A, X->physical X, etc.

[ndeadly]

@abjugard it's kind of on hold for the moment for a couple of reasons. Firstly, I would like to release it alongside a nice GUI to make toggling and setting this stuff at runtime a breeze. I've made a start on both an applet and a Tesla overlay, but both of those require a bunch more work. The other issue is more a a design one. I am still a bit undecided about how controller profiles should work. Should each controller have its own settings page? Should profiles be more of a generic concept that can be loaded and saved and applied to controllers at will? Should settings persist through reboots? How to uniquely identify a USB controller (in a future release) in order to apply its profile, etc etc. None of these are problems I can't solve, but the decisions need to be made before committing to writing the GUI properly, and I haven't had enough time for either of those lately. My top priority for now is getting Bluetooth LE working. I see this involving a bit of refactoring of the controller classes. After this I think it might become a bit more clear how to proceed with this.

If you find the inbuilt remapping too much of a pain in the arse (this is also something I am thinking about addressing), for now I might suggest you just modify the source to set the default mapping as you please and build it for yourself. See

MissionControl/mc_mitm/source/controllers/xbox_one_controller.cpp

Lines 113 to 116 in b076bc2

	m_buttons.A = src->input0x01.old.buttons.B;
	m_buttons.B = src->input0x01.old.buttons.A;
	m_buttons.X = src->input0x01.old.buttons.Y;
	m_buttons.Y = src->input0x01.old.buttons.X;

[abjugard]

Makes a lot of sense.

If you're interested in opinions on the questions posed; settings should definitely persist across reboots, and I think that it makes the most sense for settings to apply to one specific controller. Does USB controllers not advertise some ID that can be used for that?

I don't think a Tesla overlay is really necessary if you build an app, will people need to change these settings from in-game? It might be cool depending on the type of settings available I guess.

In general I'm actually a bit surprised there hasn't been a generic pluggable settings app written for Atmosphere and associated modules at this point.