To be honest, I could decide where to put this as it concerns both standard aircraft but also 3rd party aircraft in the marketplace (as well as those bought elsewhere). Also, there are probably other similar posts already but none that I have found seemed to be an exact match. So here I go:
I’m extremely frustrated with the lack of consistency regarding the programming of controls as well as documentation. As many users do, I’m using 3rd party software for control assignment (Axis and Ohs to be specific, but it applies to other similar products as well). Even with the airplanes included in MSFS 2020/24, there seems to be no consistency at all despite there being an SDK. It literally takes me hours sometimes to figure out all the correct bindings for a certain aircraft. It’s an absolutely horrible user experience!
It’s clear that with 3rd party products, it’s neither the responsibility nor under Microsoft’s control what developers do and I also know that sometimes, there are good reasons for a developer to use a non-standard variables etc. but I really expect the standard aircraft included in the sim to be a good example and consistent. Microsoft should enforce that from the external developers they are using! Also, for every aircraft, there should be some mandatory documentation of the bindings/variables used that are accessible from within the sim so that if there are discrepancies, the user has a chance to look it up without having to search the internet for hours or engage in hours of trial and error! The marketplace products and especially the standard aircraft should set the standard for all developers.
The lack of consistency between the standard airplanes is a sign for me that there was a lack of proper management of the developers both internal and external.
I mean; I share in your frustration sometimes when I spend a lot of time setting things up that should take mere seconds and end up consuming many hours.
Conversely, it can be very satisfying to finally have that StreamDeck profile working to the extent that you can manage a flight more or less without having to chase impossible clickspots with your mouse in a shaking cockpit.
Since all airplanes are different and there is a large community of players who expect fidelity in the modeled systems of their addons, a complete standardization of controls across all main systems is not achievable; complete standardization would require complete dumbing-down of the system capabilities (we’d be going back to the days of the very first flight sims)
But I do think that developers can do more to help us with building our cockpits by providing documentation of the custom variables and h-vars and the like that they introduced in their products.
First a clarification: With standard airplane, I mean the aircraft that are shipped with/included in FS2020/FS2024. Sorry for the confusion with my wording before.
Also, I‘m not talking about some aircraft specific special system like an FMS for instance. I‘m talking about spending 30 minutes and trying 5 different variables/Axis just to get the rudder pedals to work by trial and error.
I‘m all for advanced systems modelling but I‘m talking about the primary flight controls or basic engine controls like mixture levers that will not work consistently even with the standard airplanes (by which I mean the airplanes that are included in FS2020/FS2024).
There could always be a reason for some custom coding as it is with the SWS PC-12 and it‘s rudder-aileron interconnection for example. That‘s all fine by me. But for quite a lot of airplanes (including „standard“ airplanes as per my description above), there is not enough documentation available or it is outdated.
To me, that is part of being a simmer.
Simmers study/learn about their controllers and the associated controls to bind for them.
I think the vendor of the rudder pedals would be the source to provide the bindings in FS2020/2024 for it.
Note that this response is due to my limited knowledge.
I have a Flight Stick with a Throttle. (VKB Gladiator NXT EVO)
I don’t have any mixture levers to be concerned with.
Count me in a frustrated… there should some sort standards-n-practices, for these control variables.. Spad has monitors, where you can try to make sense of it.. sometimes you can dig into XML files, and grope for things that look like what you’re looking for.. even then it can be hit and miss .. variables that can only be toggled vs synced on/off with hardware, etc..
I totally agree with you there that people shouldn‘t expect a flight simulator or one of its aircraft to just work out of the box with a controller.
I actually hate it when filght simulators try to automatically figure out the buttons and axis bindings because with my setup, it‘s impossible for them to get it right.
I have a modified Microsoft Sidewinder Force Feedback 2 with an extended stick and a Thrustmaster Warthog Stick on top of it. I also have a couple of Saitek TPM units as well as another heavily modified joystick to work as a helicopter collective. With that, I always get a lot of wrong assignments and usually completely delete ALL bindings and start again from scratch. I‘m totally fine with this. I‘ve been doing this now for almost 30 years…
BUT… When I set it up, I should not have to guess which one of the 5 possible variables will work. The recommended variable as per the Microsoft SDK should be used and if not, it should be documented - best directly inside the sim, so that we don‘t have to start a lengthy inquiry into what variable the developer might have used (and then also what input range he might have used).
Of course, in the end, 3rd party developer can and will do what they want and that is fine/necessary and beyond the control of Microsoft/Asobo. But they should at least set the bar with their own aircraft (and herby I also mean the aircraft which they outsourced to 3rd party developers) and try to avoid having such a mess with the controls there, provide the proper documentation and an the possibility (inside the sim) to find that sort of information quickly.
In P3D FSUIPC had the possibility to record a macro. During recording all keypresses and mouseclicks were stored in a file. Playing back this file could then be bound to an external control.
This allowed to trigger everything in the sim even if there was no accessible variable.
MSFS does not support this anymore.
Because there are no standards (and in my opinion will never be) this would be a nice feature to be implemented by Asobo.
