Override directory for joystick definitions

[fading terrace]

This is something that has been on my mind for a while, but between newer versions of VKBDevCfg and the recent call for feature requests on the new UI, I am starting to consider this again.

Basically, we bundle joystick definitiion files with MF Connector that are both helpful for giving buttons more intuitive labels, and essential for using advanced features like LED outputs. This works fine for basic joysticks where the mapping between physical control and button number / axis type is relatively fixed. However, it breaks apart when the controller is in itself customizable in a way that this mapping becomes dynamic. Which is something that I, as a user of a VKB-heavy setup and the person who handled the VKB integration, have run into.

In the past, I have provided replacement files for the newer stock configuration, as well as a little CLI tool to generate config files. I would also think that a built-in GUI definition editor would be unnecessary feature bloat. For the future, VKB is actually including a MobiFlight definition exporter in their configurator tool (it is already available in experimental versions). But there is still a limitation that changing a definition we bundle creates conflicting files, which may be overwritten by future updates.

So I propose a minimal-effort solution to this. An override folder that the installer will never fill. If a file is in there, it gets loaded before the standard file. If not, proceed as usual loading the first matching file found. This way, both the "alternative variant" and the "external tool export" use cases can be covered without adding significant scope to the joystick definition feature.

Some background on where that can happen:

One controller where this issue is fairly prominent is the VKB STECS Standard/Max Modern Throttle. The grip features swappable button/hat switch modules, with varying number of button actions per module. As a result, when you change out a module, the button numbers of every button after the swapped module change. This includes the button panel in the Standard/Max varieties, where suddenly different button numbers correspond to the latching lever and the rotary encoders.

To complicate things further, newer hardware revisions with added functionality come with a different default configuration, so even for out-of-the-box use a file swap may be needed.

[latent rain]

yeah

this is definitely a whole new problem

once the release is out, there might be more head room to think about it

right now every change will break the profile, right?

The entire HID Controller system wants to be overhauled anyways - that might be a good opportunity.

[noble cloud]

Could this be solved by asking the user to press a series of buttons displayed as photos on the screen? The result of the button inquiry could determine what type of module is installed in each position by using the button inputs unless the user changed it from default (which is rather unlikely)

[nova sphinx]

This is a bit like how some Linux operating system installers determine the keyboard layout.

"Press the following keys in the given order, on your keyboard. If a key is not labeled on your keymap, ignore it".

It is quite specific to VKB devices only at this point, I wonder if there are other devices with similar modularity?

[fading terrace]

Of the ones we support with built-in code and definition files, I believe VKB is the only one. I believe SimAppPro may have some degree of customization for the Ursa as well, but there is less motivation to do so since most of their panels are standalone devices.

Virpil has some modularity as well with an aux port on some of their controllers, but also much less complexity

[nova sphinx]

yeah, I think the EFIS devices are also connected to the main panels

but there really is only one way they can be connected if they exist

the vkb ones are more modular and can be assembled in several ways

the grip handles would be maybe another case

because those are usually shift register and have a number of buttons but we dont really treat shift registers as "modules" either, they are always treated as devices in the arduino

and you dont generally expect to be able to move them around the same way

[fading terrace]

A lot of the fancier controllers allow the user to customize some of their mappings, as far as I understand it Virpil just straight up hired the guy behind MMJoy16, a DIY joystick firmware for ATmega32U4, and thus they have something that just lets you remap stuff from scratch. Not sure it is used except to turn one of the dials on a button panel into a mode switch, though. They also have recently introduced swappable multi-directional switches in the CDT-Vmax throttle and the FLNKR stick, but from what I understand that is more a case of having different caps that restrict some directions, not full-on electronic addition/removal of button lines.

But a lot of that is also hearsay and extrapolation, only Virpil stuff I ever set up was a set of pedals when I was with Monstertech at Citizencon (and I was there for VKB to help set up their sticks on the rigs)