Hi! I would like to discuss a topic that I think others may ponder occasionally but maybe doesn’t garner the needed attention. These days, unlike in days gone bye-bye, we enjoy some really great hardware (peripherals) when flying in MSFS. These peripherals can be quite pricey and so, become a major investment in our hobby. The problem for myself and I believe many others like me is trying to easily and fully utilize these peripherals. This became very apparent once again when trying to bind controls in the aircraft to my peripherals in the new MSFS 2024. I had hoped it would have improved in this new edition. When setting up these devices to fly an aircraft in MSFS we must match buttons, switches, and levers in the virtual cockpit with the buttons, switches, and levers available on our hardware (peripherals). Its typically referred to as ‘binding controls’. But the problem is the current structure of key commands in MSFS is antiquated and needs a major overhaul to bring it to modern expectations. The current structure has been brought forward over the decades (I was there in the beginning) from previous versions of MSFS mostly unchanged. Therein lies the problem. The early history of peripherals still dictates the current use of modern peripherals and has not been improved to match todays hardware capabilities. Not everyone makes this steep investment in hardware and will enjoy MSFS without major issues using simple peripherals with a keyboard and mouse but those of us who have made the investment are still struggling with binding our controls to make as little use of the keyboard and mouse as possible.
IMHO, I believe the current key command structure could possibly be totally eliminated. Say what! Standby, let’s think out-of-the-box for just a moment. Key commands which are nothing more than a control function (call a function gear, flaps, lights and such) were written/listed in MSFS for any and all types of aircraft controls. These functions are predetermined actions. This created hundreds of key commands. In reality these functions actually duplicate switch and lever ‘actions’ many times over. For instance, how many different key commands are listed in MSFS to control fuel systems, throttle controls, or flight controls that may or may not properly match those in a virtual cockpit? This creates confusion and at times quite a bit of frustration trying to find bindings that work properly (been there done that). Why do we need to have an individual function predetermined for each and every type of control across different aircraft? This approach is antiquated.
For example, a beacon light switch is typically a two-position latched switch. You flip it on, you flip it off. Step into any aircraft and start counting how many of these type switches you can find. Let’s see, the Nav switch is typically this type switch and I could go on and on through the entire cockpit and find more like this. That one single switch action covers many similar switches in cockpits across many different aircraft. The only thing different is the function label attached to the action. Yet we still have hundreds of key commands that duplicate these ‘actions’ that are fewer in number by far than the currently listed functions. We get lost in trying to correctly bind all these different functions to the buttons, switches, and axes on our peripherals and still sometimes you cannot find one that works with your peripherals as desired with ease. Bottom line, the current binding system is built around ‘functions’ that duplicate switch types. It should be the other way around, a few switch ‘actions’ that are labeled when the action is detected in the virtual cockpit per the aircraft developers coding. Poof, key commands wouldn’t even be necessary, more on this shortly.
Think about ‘actions’ a bit more. Most ‘buttons’ in a cockpit are either a momentary push button or a latched push button. Latched meaning it remains pushed in when released. Momentary because it returns to its original position when released. A toggle switch can also be momentary or latched. Now, these alone will cover just about every switch in a cockpit, take a look see. There may be special cases. You might have a three-way ‘rocker’ switch. Plus, we also have levers which in computer terms is an axis logically seen as a set of values between 0 and 100 (the full movement of a lever). That covers just about every aircraft cockpit you might encounter. Again, why do we need all these predetermined key commands looked at from the perspective of a function listed in MSFS? Functions should only be a label for one of the above described actions. Again, poof, no more key commands. If these actions can be auto detected in the ‘virtual cockpit’ (and they can) then ‘labeled’ as to their function per the aircraft developers coding this would make it super easy to make control bindings to the available buttons, switches, and levers on our peripherals. With the right ‘options’ to configure these bindings the flexibility would increase a hundred-fold. I’ll provide simple examples of this shortly. Has an update for control bindings been passed by because the complexity built into MSFS is like untangling spaghetti?
Well, I would like to hypothesize a revamped bindings system further by theoretically creating a new control bindings interface in MSFS from scratch. I’m not a software engineer but I have coded programs many years ago that make me wonder about this but, chime in with your own ideas if you like. Every aircraft used in MSFS is coded by a developer which must make all those buttons, switches, and levers work for the sim pilot. Now as an example, there is a third-party payware program used externally to MSFS called SPADneXt that can detect the buttons, switches, and levers when moved in the virtual cockpit. This is one of the powerful features of SPADneXt. Many advanced sim pilots augment their bindings using this program to ‘get around’ the current key command system when it fails to provide the necessary bindings. I tend to avoid using external programs which should be natively integral to MSFS anyway but sometimes you can’t get around this. So, why cannot this same method be used in MSFS to automatically detect buttons, switches, and levers in the virtual cockpit to identify actions then enter the detected action in a revamped control bindings interface within MSFS. Think about that, no more searching for the correct key command amongst the predetermined hundreds currently listed in MSFS. All the predetermined key commands are no longer needed, eliminate them all. You would configure (build) your control bindings list for each individual aircraft variant based on the actual switch action detected in the virtual cockpit. This would save a lot of time and frustration.
Let’s Imagine a spread sheet type binding screen. One line on the spread sheet would represent an automatically detected action (inserted at the time it is detected). This type interface would allow you to scroll down through all the assigned bindings on a single screen. You wouldn’t need a separate list for key commands because they wouldn’t exist. Only the bindings that have been activated would be listed for the selected aircraft variant. Also, the detected action would be identified and labeled per the aircraft developers coding. The actual function is now only used as a label. For example, just like the beacon switch, the two-position switch is detected and per the aircraft coding recognized (labeled) as a beacon switch action. Simple.
Further, on each control binding line, you would have maybe four click spots to determine how you desire to bind the cockpit action detected to the Buttons, Switches, Axes (levers), or Knobs on your peripherals. We’ll discuss these four shortly. Let’s say I have auto detected the movement of the flap switch in the Bonanza G36. That switch is depicted as a three-position latched toggle switch in the virtual cockpit. The three positions are Up, Apr, and Down. Logically (internally), the coding might identify each position as a 0 for Up, 1 for Apr, and 2 for Down. Another possible logical combination could exist, an increment/decrement of the flap switch seen as a 0 for decrement (retract flaps) and 1 for increment (extend flaps). That’s it as far as the virtual cockpit side of the binding is concerned.
But now, we need to bind this action to a button, switch, lever (axis), or knob (an encoder) on our peripheral. Can we actually configure this flap ‘switch’ to a lever on our peripheral? Yes, but let’s first examine binding the action to a switch. To do this on our new binding screen I would tap the click spot on the line to configure (bind) the action to a ‘Switch’ which pops open a window with binding options. Let’s say I have a three-position latched switch on a peripheral just like the virtual cockpit switch. This can now be an operation much like we use today to auto detect the switch on my peripheral I desire to use and match the switch movements to the switch action in the cockpit. Internally the coding would recognize a logical 0 for Up, a logical 1 for Apr, and a logical 2 for Down for each position of the switch on my peripheral to bind the control to the flap switch in the virtual cockpit. This logic is not currently in any of the MSFS key commands (I couldn’t find one to bind it this way). But, what-if I don’t have a three-position switch on my peripheral? What if I only have a two-position momentary toggle switch. No problem. I tap the ‘Switch’ click spot to open the binding options window and once again move the toggle switch up to now bind the action as a decrement to move the cockpit flap switch up one position (retracting the flaps). The opposite would be true if I move the toggle switch down to increment the cockpit flap switch (extending the flaps). The computer logic internally might look like a 0 to decrement the flap movement and a 1 to increment the flap movement. This decrement/increment action is available in the current MSFS key commands. Okay, what-if I desire to use a dedicated flap lever (an axis) on my peripheral to control the cockpit flap switch? Can I do this? Currently MSFS doesn’t sport this option but it can be done if coded properly. Hypothetically, in this case we might tap the click spot ‘Axis’ on the line for the control binding to configure the cockpit flap switch to an axis on our peripheral. This again would pop up a window like the switch option to allow axis options to be configured. In this scenario the options for configuring the axis would need to allow us to create ‘zones’ on the axis so we could use the logical 0 for Up in an upper zone, the logical 1 for Apr in a middle zone, and the logical 2 for Down in a lower zone of the lever movement. Any time the lever on your peripheral moves into that zone that is where the virtual cockpit switch will move to.
Another click spot on the controls binding line might be for configuring Knobs. Encoders (a knob) are becoming more popular. An encoder simply outputs a digital signal that can be recognized as clockwise or counter clockwise movements of a knob. These can also sport a dual function, having a momentary push button action along with the dial function. You might have one or two included on peripherals that can be configured to control a heading bug adjustment for instance or to tune a radio frequency. The push button action could then be used to ‘swap’ the frequency in the radio. Of course, with only one or two encoders available on our peripherals their use may be limited if a method is not developed to easily select various adjustments such as the altitude select knob, airspeed select knob and the like in the virtual cockpit. Maybe one day a vendor will create a panel sporting numerous encoders for many of the various actions in a virtual cockpit without the need to select them, instead dedicating an encoder to the most used adjustments.
You can also have a simple checkbox per line to indicate the binding should be used across all aircraft. As far as binding controls for things other than aircraft related controls, maybe the spread sheet type interface could sport tabs along the top labeled ‘Winged Aircraft’ or another for ‘Helicopters’ and yet another for ‘Environment’ for bindings unique to those categories. Imagine new things like the ability to have an avatar (character) walk around in the simulator ‘environment’. These control bindings listed under each tab are easily scrolled through to see them at-a-glance. Another thing that might be included in the control bindings interface would be a welcomed print function to printout the assigned bindings. What a GOD send that would be to catalog our bindings in a notebook for each aircraft. Great when you haven’t flown a specific aircraft in a while and you need a list handy to reacquaint yourself with the bindings.
Can we agree our control binding system in MSFS needs a thorough review and update? If these new changes as outlined above were introduced to the control binding process the flexibility and intuitive process would be greatly enhanced and not a single predetermined key command is required to do this. Most of this capability exists today, it just needs to be spun together into a revamped binding system. What do you think? Comment below and let the discussion commence…