New Launcher Feature request: Joystick Axes tied to .key selection for different stick etc.
-
I’m going to stop calling it the Alt Launcher because I’ve embraced it since 4.35 and I think its hopefully reaching the tipping point of acceptance.
I made a message post about how the F-15 was going to be a se3lectable for the different .key at GitHub under a different username to see if there was a way to tie the .key to also different analog axis map but it probably got lost in the frenzy of pre U3 work. This would allow you to have a different stick/throttle for the F-15 and other future aircraft without building into BMS directly if possible from the Launcher.
I currently have a side mounted X65F for the Viper and while it’s throttle will work great for the F-15, I have a Virpil T-50CM Base with multiple grips that I would like to use in BMS more easily when I mess around with the F-15C. I could also see some new TQS owners that still have a Warthog maybe wanting to use the split throttle, etc. Not sure if this is possible @chihirobelmo and @airtex2019 but just a thought. Thanks for your hard work!
-
@Snake122 As it currently stands, no – it’s a BMS thing not an AL thing – only 1 axismapping.dat file.
Best approximate solution for your setup would be to keep 2 separate subfolders under Config … call them, say ‘Config/SaitekTQS’ and ‘Config/VirpilWarthog’. Then maybe a pair of little startup scripts to copy everything down into Config, before launching.
For keyboard bindings, you can probably get away with just keeping 1 copy of the BMS-Auto*.key files in the Config folder. (Although, it’s not a terrible idea to have redundant backup copies of those – if you’re handy with a diff tool you can keep the keyboard portions in sync.)
-
@airtex2019 Okay, good suggestion for that now!
I’m throwing out more for the longer term, because isn’t that what the Launcher does for us anyway, write a specific .key, devicesorting.txt, etc.? Couldn’t you have it saved the F-15 axismapping.dat as a separate .dat or .xml? Or is there something I don’t realize about the .dat?
I get that BMS only supports one, but in a way that’s what the Launcher has been doing anyway, compiling stuff like the devices to make a devicesorting.txt. It would probably take UI changes like the add for 2 .keys now and I get that would be more work and a source of more confusion. But a dropdown menu of multiple Axis Mappings that get saved and writes the devicesorting.dat when you select it and Launched? If yes, I get that is probably a good bit of work for the UI and supporting code and may not be worth it right now compared to a personal script though, and that’s alright too.
-
@Snake122 tbf I did at first consider doing exactly what I said – saving separate “profiles” in subdirectories of Config and copying them down
but that would require everyone maintain parallel configs for axismapping / joystick.cal … which is not the hugest burden, granted, but seemed like biasing for the rare case.
also I came to realize, there is huge complexity in the codebase (both AL and BMS) with regard to how it enumerates plugged-in devices, but also remembers previously-seen, absent devices (as you see in DeviceSorting.txt)… doing this in a way that worked seamlessly, reliably and dependably, regardless if you left both sticks/throttles plugged in vs swapped them out, would be super difficult.
we are definitely needing a big round of simplification and reunification of the 2D setup experiences… some single, simple file format (well maybe multiple files for multiple profiles – but not have the data scattered with implicit dependencies across key files, cfg files, axismapping, joystick.cal and DeviceSorting)
so, all I can promise, is that your scenario will be kept in mind, when designing that.
-
@airtex2019 good point with the complexity of many devices alone and then the rest! That’s why you’re the coder Thanks for keeping it mind. Off to look into my scripts for my own .dats, thanks!
-
@Snake122 ps if you do go the route of regularly unplugging/replugging, let me know how that works for you.
AL has a slightly different way of identifying devices than BMS…
AL uses a “device-instance-guid” received from DirectInput, while BMS only uses the product- and vendor-id guids.
I don’t fully understand how stable that device-instance-id is … eg. if you plug device into a different USB port or esp. a different USB controller.
This device-instance-id is right there in the name of your XML save files… so, be mindful if you see any “duplicate” looking XML files created, with same product name but different guid.
-
@airtex2019
Just want to let you know, that the AL method of enumerating devices is rock solid here so far.I began with the Warthog stick on one front panel USB 2 port, switched to the back panel USB 2 port a few weeks later, added the Viper TQS recently plugging both into a Anker Active USB Hub connected to the back panel ending up with this Active Hub on the front panel USB 2 port right now.
I disconnect the toys regulary, they occupy my workspace so they need to be moved out of the way for daily work. I even started AL without anything connected several times. I never had a single issue in AL with this. Devices where always right and didn’t loose any config/assignments or the like.
Totally unrelated to AL but annyoing:
I often have an issue with the Warthog stick shown OK in the Windows/TM Joystick panel but the stick being plain dead (in terms of Axis movement shown in the Joystick control panel, registering button press etc.). It’s just a matter of replugging the stick to make it work again. It doesn’t matter whether the stick is connected directly into a USB port (back or front) or connected via the active hub. Happens in all variants. It’s something about the TM firmware/drivers. I already disabled USB power stuff in Windows, so powermanagement should not be the issue. As long as it’s just a matter of replugging the device, I can cope with that.