Imagine you’re designing a flight simulator and realize that sometimes the user will hold down a keyboard key or joystick button to make scrolling something faster. Maybe they want to increase their heading bug or their autopilot altitude setting faster so they hold down that key or button.
One thing you could do is nothing. Just let them hold down the button and let that input increment up by one repeatedly. That can work.
Or you could give the user some help. Maybe you could code in something where if the game detects that they are holding down the button for a few seconds, then you make that increment go up by 10 instead of 1. They’ll get to where they want to go faster! Maybe create a Boolean (true/false) variable called “control acceleration” and set it to true if the button is held for more than a few seconds, and set it to false when the button is no longer held down. Ok, looks good!
But you made a mistake. Instead of checking to make sure that the button or key being held down is the one that’s actually doing the heading bug increase or altitude setting increase, you instead make it so that if ANY button bound to a recognized command is being held down, then the “control acceleration” variable is set to true.
This is where the bug comes in.
There are peripherals with buttons that will have a constant “pressed down” state. One example could be a toggle switch. If the toggle switch is in the up position, the peripheral could be constantly sending an active command to the game, as if a user was constantly pressing down a button. Same if it’s in the down position. The Honeycomb Alpha Yoke operates this way with its switches in its base. Some other peripherals do as well.
So now, just by virtue of having a peripheral giving constant input, the game sets the “control acceleration” variable to on, and all heading bug changes, or altitude setting changes (and I think some other changes as well) will be at 10x the increment.
Anticipated questions:
Q: Wait, I have the honeycomb yoke and I have those switches in the base bound to commands, but when I click on the heading knob in my cockpit to increase the heading, it increases by 1, not 10.
A: Yes. Apparently, this “control acceleration” state only applies to commands that come from binds, either keyboard or joystick, that are bound in Options->Controls, not from click interactions with the virtual cockpit.
Q: I’d like to test your theory but I don’t have a peripheral.
A: You can test this entirely with your keyboard. Hold down “F7”, which increases flaps by default, for more than 3 seconds, then press “Left Ctrl + Insert” ,which increases the heading bug by default, a few times. You will see the heading increase by 10 instead of 1. Now let go of “F7”, wait a second, then press “Left Ctrl + Insert” again a few times. The heading will increase by 1 again.
Q: I am having this issue but I can’t find what button or key is being held down and causing it.
A: If in Windows, go to your USB Game Controllers settings (Click Start->Type “USB Game controllers” and it should appear). Then go through all your peripherals and look for one that by default is keeping a button or switch pressed down (filled in red circle). That is your culprit. You will need to unbind that button or switch in Flight Simulator. This doesn’t apply to axis inputs like yoke or rudder.
Q: So how should Asobo fix this?
A: They can change their code so that the “control acceleration” state only turns on if the button that is being held down is the same as the one for which the increment should be accelerated. In other words, only make the heading increment by 10 if the heading increment button or key is held down, not other buttons or keys. I am guessing that somewhere in their code they currently have a function which does nothing except detect if a bound key/button is held down and if that’s the case, control acceleration occurs for everything. It needs to be more fine-grained than that.
Q: Why are you incrementing your heading bug through a bind? Why not click in the cockpit like the rest of us? If you do that, you won’t have to face this bug.
A: Some of us like to have our peripherals interact with the cockpit further than just the basic inputs. For example having a rotary switch tied to the heading bug is a neat way to interact with the airplane.
Q: How do I fix/workaround this for myself?
A: Make sure you unbind any key or button or switch that is causing constant input. The downside of course is that now you can’t use your peripheral for its intended use. One workaround that I found that is really cool is linked below. The method is to have a program wait for your constant input buttons to change states, then trigger a single short button press from another virtual joystick. Then when you bind commands to that virtual joystick, nothing is held down anymore.
https://drive.google.com/drive/folders/1kIJlzjDzELPxd2LpRxzlTmZsuqmXHB4F
By user: pjoerg
As a final note, I could be wrong about some things! Please let me know if that’s the case and what sorts of experience you’ve had or experiments you’ve done, but first please make sure you read this post and be clear on what I am saying! Thank you.
