This. This. This!
1 Like
Here is my set up (to provide another user-case):
GA/Airliners
- HC Alpha Yoke
- HC Bravo TQ
- Logitech flight pro pedals
- Xbox controller (for camera work)
- Keyboard
- Mouse
- vJoy virtual device
Helis and high performance aircraft
-Logitech X56 stick
-X56 HOTAS
- Then all the other devices as with GA.
I have to physically switch the X56 devices for the Alpha and Bravo when flying helis
I use a whole bunch of other peripherals too but these are not read by MSFS as controllable devices (Logitech flight panels)
1 Like
My setup:
Yoke aircraft
CH Yoke
CH Pedals
Logitech Throttle Quadrants x2
FlightSimStuff TPM
Stick aircraft
CH Fighterstick Pro
CH Pro Throttle
Switches
Logitech Multi Panel
Logitech Switch Panel
Custom-made button box (own build) with dual-concentric rotary encoders and pushbuttons for GPS and NAV/COM radio operation.
I also integrate a Stream Deck for a few things
And always, always use TrackIR
1 Like
Thereās some caveats to this that unfortunately canāt be easily worked around.
#1 Caveat The major one is the sim needs device detection stability for an enhancement such as auto control profile switching to work consistently and reliably.
What do I mean by that?
In order to save profiles on a per plane/per device/per preset basis you need to be able to map planes to devices to presets. The key here is the device ID. If that device ID is allocated by MSFS, and if it changes due to the user plugging/unplugging different devices and device IDās get swapped, that basically means you need to manually remap all your presets, as you canāt effectively rely on the original device Idās mapping back to what device they originally referred to.
This isnāt a problem for MSFS because itās saving things on a device level, so really doesnāt care.
But if becomes an issue if things are saved lower down the stack at an aircraft level that needs to be mapped to device.
While it may be possible to write some code to check this, remap and resave, thatās also a performance killer to do every time on loading, and also quite complex and tricky to test/debug given the device configurations Iāve seen so far.
So for now, Iām going to keep it lean and mean, based on a simple static configuration of plugged in devices that can be relied upon to deliver consistant device ID mappings once they are saved.
If that device linup is changed, you may need to manually remap some of the plane/device/presets as a result.
Thatās not an issue with a small plane collection, but I have seen users with 400+ aircraft, so it bears thinking about how you might want to manage your mapping strategy to cater for changed device situations. Along with that is possibly thinking about how you might be able to make your device connections static, or minimise deviceId assignment/swapping if devices are swapped by USB port ordering etc. Some testing may be needed on an individual basis to get more clarity on how your particular system maps devices to Idās, and how that changes on swapping/adding new ones.
Still, Iād like to get a sense of how big an issue this might be, so Iād like to know:
How often do you plug/unplug devices, thereby changing the device lineup that MSFS sees in the Controls Options?
I had been wondering about how your app would handle this exact scenario.
Re physical changes. Not more than once a day with the control setup I described above. Physically remounting the Alpha for the X56 is a bit of work and not something I would do too often.
At the moment I do not have both sets of controls plugged in concurrently as I lackthe slots on my powered USB hub. I also worry about the extra power demand of the X56s and conflicts, although with automatic profile switching it would be easy to assign blank profiles to plugged-in devices that you do not want to use with with that given aircraft. The solution for me will be a bigger powered hub with more slots and an excellent power supply.
Other thing to note: SPAD has a nice feature which is that it detect and then (if you start SPAD in Admin) automatically manage the Windows power control for USB devices to take them out of the default low-power mode to prevent Windows putting devices to sleep after inactivity - ie your yoke when go back to manual control after a period in autopilot. The device may cause a CTD as it āwakes upā after being sent to sleep by Windows. The SPAD feature prevents this (you can do it manually, but many a casual PC user may not know how to do this as itās buried in device management). I should note though that CTDs are now much less common with device status changes after Asobo worked on this problem.
Iām guessing this is one of the reasons why itās not implemented in the base sim, as itās not an easy use case to reliably solve. But there are strategies that can be used to minimse disruption and manual reworking, which is the point of starting this conversation.
I think this is probably the simplest, easiest solution.
Thereās a very wide range of device scenarios here, unfortunately, and making it flexible enough to cope with an infinitie array of dynamic switching scenarios is not really feasible atm.
The way I currently handle this is the same as if a preset has been renamed between sessions, as there is no way for Aircraft Manager to detect that except for on initial load. So if it detects a saved preset for a plane no longer exists (due to preset renaming or device change) the saved preset is deleted and that slot reverts to blank. It will also be configured to only handle up to 12 devices.
That said, I do have another approach to this Iāll test out to see how well that handles changed device configurations between sessions.
At the moment my solution to this is by default itās blank, if you leave it blank nothing gets switched.
Only if you select one of the available profiles for a device will it get switched when you select a plane.
ie: the āDefaultā slots in the video are now blank. Also makes it easier to see which ones have been set.
1 Like
Day 1 customer here!
At this point, Iād settle for a drop down menu for each controller, to select the aircraft Iām about to load, instead of doing the left/right arrow dance.
4 Likes
Pretty identical to what Iāve set up.
I donāt have the Xbox controller (sounds like a good idea!)
I have a TM16000 HOTAS.
Everything is connected to a USB3 powered hub, and I just power off the HOTAS when Iām flying GA in MSFS, and turn off the Alpha/Bravo when Iām flying fighters in MSFS and DCS.
Iām about to buy under-desk mounts for the Alpha/Bravo. It will be great to reclaim the desktop for my keyboad/mouse.
Given that the sim already has a profile manager that can save sets of profile settings, all that is missing is a way to assign a profile to a list of specific airrcraft. Iād not expect that to be so difficult.
1 Like
I have a desk with an undershelf that Iāve got the bravo and alpha on, which keeps the desktop free for the saitek panels and an 11" monitor is use for my PFD/MFD /. So still no space for the key board and mouse - the keyboard goes on a side shelf and the mouse is actually a trackball mounted to a kneeboard!
The Control Options screen doesnāt save sets of selected device profiles (afaik, unless I missed it). Each device just has a āCurrent selected presetā, thatās it. Each device also has a list of presets that have been added for that device, including any MSFS ones and the default profile, managed through the preset manager interface. The preset manager interface could use a rework too, you should be able to switch presets within it but you canāt.
You can hot unplug/replug devices, but the deviceId wonāt be reassisgned unless you do a restart, so hot plugging isnāt recommended either. Sounds obvious, but someone is always going to do it and expect it to work!
Iād counter this by saying, if it was that simple it would have been done already.
Then thereās the dedicated resources needed to deal with the inevitiable issues.
Q: I havenāt actually checked, is this on the feedback snapshot list at all?
From my direct experience peeling back the layers to see the different ways it could be done it isnāt that simple once you dig into it. Thereās lot of different use cases with devices and saving confgurations for recall/reset, not to mention it needs to be performant. Changng the active device in the control options is not instantaneous, thereās some work under the hood going on to do this that also needs to be factored in when you want to bank switch all (or even some) devices at once. Ditto for device presets, though less intensive.
Some people have upwards of 400+ aircraft as well, and thereās also a wide range of planes & potential preset configurations people may want - in addition to generic presets. Obviously you canāt cater to all them, it has to be a general solution, but it also has to be flexible - to a degree.
So, from my perspective, itās a tricky little problem to solve for at least a good % of use cases.
I know most people donāt care about any of the above technical implementation issues, they just want to āmake it soā & use it - which is fair enough - but the reality of implementing functionality is always more complex than it appears on the surface. That applies to MSFS across the board too.
all that is missing is a way to assign a profile to a list of specific airrcraft.
Sounds like an interesting approach though, an inversion of the aircraft first approach.
Could you elaborate a bit more on how you would see it working, from setting control profile setups to aircraft, then all the way through to hitting the fly button so an aircraft has all its selected presets activated? How do you see it working within the context of the current Aircraft Selection and Control options UI? What would it look like, and how would it flow in terms of user actions to get it done?
It might be worth exploring.
1 Like
This now works with changed device setups between MSFS sessions, ie: cold switching devices between MSFS restarts. 12 devices max. Iād love to cut that down for performance reasons (switching preset banks is actually a little tricky) but it really does seem as if some people have up to 12 (or more) devices in the Control Options.
Q to everyone: What would be a reasonable number of devices to cater for?
Edge cases that I canāt cater for:
-
Multiple devices of the same type, like Elite Dangerous type setups using two T160000Mās. I donāt have two of the same device, so donāt know what MSFS is doing with the device names there. If anyone has two of the same device Iād be curious to know what they are named as in the Control Options. Ie: are they both T16000M or T16000M1 and T160002 (or similar).
-
Aircraft named the same. A rare use case, but could possibly occur with 3rd party aircraft of the same type from different developers that conflict with the same meta data have the same name. Canāt do much about that Iām afraid, except donāt install both at the same time.
I have 2 vJoyās - 1st to combine multiple physical devices into one using joystick gremlin, and the 2nd for SPAD virtual buttons and they both show up as āVJOY DEVICEā but can have different profiles selected. You cant tell which is which until you look at the sensitivity page to see what axes move.
Thanks for the confirmation.
Iām not sure I can cater for that use case at the moment, but good to know it would be an issue.
Not sure where MSFS is pulling the name from (device driver or windows description or ?) so donāt know if it can be renamed so MSFS picks that up. Pity they canāt just internally number duplicate devices, it would be the simplest solution.
1 Like
I use two Logitech Throttle Quadrants and they both show up with the same name (which escapes me right now). In fact, they occasionally get reversed in order in the controls screen and I canāt tell until I go back to the plane.
Thanks also for the confirmation.
@smitty9792 @CharlieFox00 I actually think this is a bug that should be addressed, especially as you note they sometimes get swapped. That indicates that internally itās also having issues keeping things straight because it canāt distinguish them.
Have either of you submitted zendesk bugs on on it?
If not, I would urge you to raise it as an issue.
1 Like
Wile I certainly appreciate the work being done on an outside program, to be used as a work around, I donāt see that as a long term fix. I actually see it as one more variable to possibly cause a conflict, or CTD in the sim. Iād much prefer for Asobo to either streamline the controller profile selection process in the options menu, or create a way to permanently assign controller profiles to specific addons.
3 Likes
Could you use the GUID to differentiate them? No idea where you get that from, but these are the files that DCS creates for my three Thrustmaster MFDsā¦
Theyāre sold as a pair so 1 and 2 identify the left and right. Iām using a third for the centre, so thereās a second ā2ā.
Nope, no access to it.
Iām only able to access certain device info, and the only real distinguishing feature is the name. MSFS not naming duplicate control devices uiniquely based on detected GUID (or similar) is a bug on their side, and not worth investing the time to develop a convoluted workaround for.
Especially, as @CharlieFox00 points out, it already causes issues with MSFS control options swapping.
Itās a bug, needs to be addressed by them.
1 Like