Heading Increment Bug (10 degree instead of 1) Explained

You know what? You don’t want a solution? Fine, I won’t give you one.

My simulator no longer has the bug and I’m satisfied with that. Unfollowing the thread. Goodbye.

1 Like

This is a bug inside the sim dating for years, apparently. Contrary to what others might be claiming, the bug is not fixed. There are various workarounds depending on your hardware. For Honeycomb hardware some options have already been mentioned in this thread. For Thrustmaster hardware i recommend the Target software that comes with your hardware, so you don’t need to buy any other 3rd party software.

Just to be clear, this affects any and all hardware that sends a hold signal, even if it’s your keyboard and you’re holding a command pressed.

1 Like

You mean the "spad.next, right? Why should we have to go true this to get the problems fix? Should it be Asobo’s problem to fix? Just curious! This software seams very difficult to use and setup!!

Of course it’s Asobo’s problem to fix. This isn’t something affecting just Honeycomb hardware. Like i said, the problem can be easily reproduced with just a keyboard, no other hardware connected.

Voor Honeycomb alpha and bravo there is also a very good freeware tool that fix these bugs within MSFS.

It’s an Asobo bug caused by any hardware that has switches that stay permenatly on.
The bug has been in MS flight sims for years.
You can avoid the bug by using various 3rd party software solutions

I recognise that if it was any easy problem to fix they would have done it by now! Remeber this has been around for years so I decided instead of complaining I’ll just start fixing (or more to the point avoiding) the problem.

So I decided to use the free vJoy/Gremlin soution with my Alpha and Bravo. It takes some time to set up but once done you won’t look back. I’ve been succefully using it for 3 months now

Here’s my Solution to Avoid the Bug
This just shows the basic solution to get you started flying a Complex engine GA aircraft with Throttle, Prop and Mixture controls. Once you have this successfully working you will be able to see what I’ve done to setup Bravo profile and you will then be able to configer the throttles for other types of GA engines.

If the bug is still there it means you still have an “always on” switch maped on your alpha or bravo profile. Use these instructions to find that offending switch

If you still have the bug than it’s likely you incorrectly created a Gremlin macro ; usually it’s forgetting to assign a “released” action

By using gremlims input viewer you can find the incorretly created macro by switching/rotating every switch and dial one at a time on your Alpha and Bravo to see if any of the vJoy buttons permenantly stay on (red)

So spend a few hours implimenting one of the many workarounds people found and then you can 100% enjoy the full functionality of the Alpa and Bravo with FS2020

To be honest even if Asbo do fix the problem I’ll still continue to use my vJoy/Gremlin solution because I have made some quite complex macros using Gremlins Condition function (“if this than do that”) to further extend the functionality of my Alpha & Bravo


Considering this is a function that detects any long control press, even keyboard shortcuts, and accelerates all controls around the cockpit… i don’t even want to know how many functions they have to remove this thing from.

my point exactly

I also wonder how the sim would handle a constant on state switch that is continously sending data to the sim!

The sim would have to constantly monitor that switch to check when it’s been released (and remember it’s not actually released, it just switches state to another button number). That’s all gotta suck up a few cpu cycles which none of us can afford to loose!

The only way I can see them finding a solution is to develop a built-in addon that replicates something like the vJoy/Gremlin solution. Something that is easier to use and specific for FS2020 so that it’s easy to set up!

It’s not the ideal situation and would sort of admit defeat for Asobo but it would solve(avoid) the problem and be suitable for all controllers that have these types of switches

One good thing about Gremlin is it alows me to use my Fanatic racing pedals as a rudder :slight_smile:

The fix would be to not accelerate all inputs, but just the one that’s being held down. Eg if I hold down a key to trim up, then tap the increase heading bug key, the trim up being accelerated should not cause the single press for adjusting the heading bug to also be accelerated to 10°

There should also be a setting against the control mappings to enable the acceleration. Some inputs I don’t want to be accelerated (trim being a prime example - I just want that to increase linearly when I hold it down), but I could also use this setting to disable acceleration on inputs that it makes no sense for; eg “Mag - Both”. That is currently an input on the Honeycomb Alpha that causes this 10° bug but it makes no sense for that input to be accelerated in the first place). Those inputs (like mags) just shouldn’t accelerate by default but if there was also a setting for it (I don’t want acceleration for trim but I wouldn’t be surprised if other people do want it) that would be fine too.

Either one of those two changes would solve this bug without the need for 3rd party software like FSUIPC, but having both would be great as it would enhance the current experience even if we ignore the bug!

It’s not really a matter of lots of functions they would have to remove it from. There should be a low level change they can make to how inputs are read / mapped without requiring a change to each individual control action


The only way to me is to recode the logic:

1 Like

I’m not a game developer but a developer, still. I doubt that this is how it works.
Old school method would be to react to interrupts created by input devices. I’m pretty sure that this is not used anymore as it is inefficient since it interrupts a process until the interrupt is handled.
Your method would also imply that every configured input (whether it’d be a key, axis or button input) would have to be monitored constantly as the state of not being pressed (or the axis value) has to be observed, as well.
I would assume that the code polls every x cpu ticks for input signals/states and will have to sync differences in input device/button states to the cockpit switches etc as well as reacting to axis inputs. That has to be done all the time, anyway. I don’t think that having or not having constant-on buttons impacts code performance (of the simulator itself) in any way.
The only impact I could think of would be if an input signal queue is being used which would then get flooded by those constant-on buttons.
As I said, I’m not a game developer so I don’t have insight into how DirectInput? works here but I don’t think that performance impact is an issue here unless you’re on potato hardware. Please correct me if I’m wrong and you have a little more insight into this.

I actually don’t think changing the code is the hard part here. What is complicated is figuring out a way to fix this so that it does not cause problems for existing users.

I would hope they could fix it in a way to recognize always on switches and configure the cockpit switches to match. This would make things like starting in the air a bit more predictable and would aid in using the sim to practice landings for example.

So last night I used SPAD.NEXT and I only setup the honeycomb alpha with it. I have the “CH pro throttle” install too but I didn’t change anything in SPAD.NEXT. Now the heading bug 10degree is gone!
My question is this; the pro throttle buttons must not be switches like the honwycomb or the 10 degree would still be there, right?

Looks like the CH Pro throttle has intermittent buttons, yes.

OK, so honeycomb should have been made the same if they know that Microsoft flight simulator has this problem for years not just MSFS 2020! I could be wrong, I don’t know.
So when you look at what they say it’s been fix (mouse interaction; fix) what does this mean if we still get the 10 degree still there!! What did they really fix? I know this is exhausting, just trying to understand before I buy SPADE.NEXT if they really will fix it , quite expensive I think! Around $40 Canadian!!

Well, temporary switches are, in my opinion, a better choice than latching switches. They simply allow for more flexibility. It’s the thing i dislike most on the Thrustmaster Warthog throttle (but i do understand that in this case they wanted to mirror the real hardware). And while Honeycomb maybe shouldn’t have compromised their hardware concept, what they should have done is provide a proper configuration software, FS bug notwithstanding.

Out of all hardware manufacturers, Thrustmaster currently ships the most complex configuration software that i know of. They allow for C like programming. I’ve seen a configuration for Elite Dangerous that was using an external program to read game variables and feed them to the HOTAS software to set lights and change configurations. And this software is about 3 years old now, and there are better options out there, but it does show that Honeycomb had no excuse to ship their hardware with 0 software support for FS2020. Had people had an easy way of changing the signals sent to the sim, this wouldn’t even be an issue.

There are free alternatives to working around this bug. vJoy with Joystick Gremlin is what I use.

1 Like

The benefit of having switches that are always in one state or the other (on or off) rather than only sending a momentary event (like a button) is that their position can be read at any time, so for example when you load into a flight your switches in the sim can be in sync with your controller rather than having to flick them all to get in sync

I can’t think of an advantage to having them being momentary other than to get around this bug


That is true, but you lose a lot of flexibility. That two position switch can only do one thing: turn a thing on or off. Or if it’s a three position switch, either turn that thing on or that other thing on, but not both at once. Momentary switches can have completely different functions mapped to them, because the two functions don’t need to be related to each other.

For example, i have set a three position switch on my Thrustmaster Warthog throttle to turn on the landing lights in the up position or taxi lights in the down position, and turn them both off in the middle. So I am accepting a compromise that i can have either one or the other, but not both. And i can’t assign some other command like, for example, gear down, because i might want both the gear and the lights on, not just one or the other. Had that been a momentary switch (like the ones on the good old X52 throttle), i could have any toggle function i want on it.

Sure, i can still use it as a toggle and move it by hand back to the middle, but that’s inconvenient.

So yeah, there’s upsides and downsides. Depends what you care about more.

I’m not sure that would apply to normal 2-position switches. If you wanted to try to use a switch for two actions rather than just one, not only would that be wildly unrealistic, but also very restrictive. You wouldn’t be able to toggle one action of the switch without also toggling the other, which would mean you are really back to having a single switch with multiple controls triggered by it, which you can do without the switches acting like momentary buttons.

I still fail to see an upside to having the switches act as two momentary buttons (other than as an attempt to get around the MSFS bug) and I think it’s wrong to say manufacturers like honeycomb should have made their peripherals work that way

1 Like