Heading Increment Bug (10 degree instead of 1) Explained

Did you try Joystick Gremline + vjoy yet?

Only problem with honeycomp is 10 degrees problem, and that problems is MSFS problem, not hardwareproblem. Same problem with other flight controllers too with on/off switch.

No. Because of corona I’m working from home, and my desk is occupied on weekdays by work gear. So I mostly only fly during weekends.

Haven’t decided if I want to go with Gremlin/vJoy. Probably not if it’s only to work around the bug we’re discussing; I can live with that until WU4.

But as I dig deeper into the configurations for various planes I may run into issues that cannot be solved with the built-in controller mappings, and then Gremlin/vJoy is something I’ll consider.

I’m also considering FSUIPC7 as an alternative, but I’m not sure to which extent they cover the same needs. Anybody?

FYI the bug fix again got delayed. First the devs said it’s fixed and coming in the next update (World Update 3). Then the community manager had to inform us that they meant Sim Update 3 (two updates away at the time). Now they discretely delayed the bug fix AGAIN to World Update 4 in the latest weekly blog development roadmap. You can’t trust ANYTHING Asobo says.

1 Like

Jummivana announced the latest delay in this very thread as soon as she learned about it.
And your account of events is entirely false. The developers never said WU3. The expectation was SU3 all along, until Jummivana had to inform us that it didn’t make it into that one, after all.

You have never been lied to on this matter; plans sometimes don’t pan out as expected in software development. Therefore, your end remark about distrust is totally unwarranted.


I’ve received my Honeycomb Alpha today and this put the whole problem in a certain perspective to me now.

First, I’d like to reiterate what I’ve written above (post #2 in this topic): this is a FS2020 bug which is well known since at least 2004, a remnant of using FSX/9 code in FS2020 for which Pete Dowson back then did implement a workaround in FSUIPC, a bug which was also corrected in subsequent versions of the franchise maybe as early as P3D2 and I’m not sure with FSX-SE (Steam Edition).

Second, the wording in the topic lead me to think there was a Honeycomb driver sending events to FS2020 but it is not what this is about at all. The switches are seen by Win10 (XInput, DirectInput, HID whatever) as either in a position or another one. Honeycomb, instead of implementing the switches as an OFF/ON toggle (only 2 positions x 1 state each = 2 states), they have implemented the switches as 4 states switches (2 positions x 2 states each = 4 states. This is more versatile in that you can use a switch position as a “SET” event, or as a “TOGGLE” event depending on how you configure and manage the input signal for the application. You can even repurpose the switches to something else than their labels because both positions doesn’t have to be controlling the same element (say switch up = gear up and switch down = flaps down - it is just for illustration, not practical use of course).

I believe, like I’ve written before, the main if not the only problem is FS2020 accelerating inputs regardless of the input source, and this is the same bug since FS9 (in 2004). In other words, it goes like this:

  • FS2020 calls Windows API to get the current button states
  • It detects some buttons were already pressed since X secs
  • It sets a global “is_accelerated = 1” in the code
  • Any further input is therefore using “Is_accelerated”

Instead of:

  • FS2020 calls Windows API to get the current button states
  • It detects some buttons were already pressed since X secs
  • It sets a per-button “is_accelerated = 1” for those which are, and “is_accelerated = 0” for those which aren’t
  • Any further same input is only accelerated if its own “is_accelerated” is set to 1

There is really nothing fancy there and this is basic input 101 in any game and program. This is exactly how the Garmin GTN and GNS bezel knobs are accelerated too in the Garmin code (I know because we intercept and control this as well in the GTN and GNS V2 for XPlane and Fltsim).

What can be done about this?

In my opinion it is very simple in fact:

  • FS2020 code must manage the is_accelerated state per control input, not globally. NB: it is maybe already the case in the code, but a bug like a typo or a mere logic error is only preventing this from working as expected. In this case fixing this shouldn’t have taken this long, which is why I believe the code wasn’t initially meant to work the correct way.

  • Honeycomb should also offer the means to alter the switch logic and signaling, most likely via a firmware update. This could just mean to flashing firmware A where each switch position toggles 2 states (like it is now, i.e up yes or no, down yes or no) or flashing firmware B where each switch position toggles 1 state (up yes down no)

  • I’d honestly prefer this comes in the form of a firmware instead of a driver because there is no need for the complexity of a driver for this. Eventually they could make a firmware update where in pressing a combination of buttons at power up you’d setup your Honeycomb for one or the other scheme.

  • Asobo and Jorg: you might want to take a look at the Alpha manual and see how the entire concept of named events and commands in X-Plane is vastly superior to the antiquated FS5 area enums and ids… It takes no additional driver nor config to setup the Alpha with XP11, it takes a special tool to map the Alpha to events with Prepar3d/FSX only because there is no way for 3rd party developers to intercept and override standard control events unlike X-Plane (standard SDK feature), which makes 3rd parties having to create their own alternate simvars the Alpha must interact with via a special application mapping the controls to these alternate simvars… There is so much to get inspired of the XP11 SDK which would tremendously benefit 3rd party devs, and this one is a perfect example in my opinion.

@Jummivana I’m glad they’ve announced correcting this problem, I just wish they won’t just issue an alternate set of commands and events to map to Honeycomb switches but instead they will re-implement the input event acceleration logic properly, otherwise, it won’t solve the problem at all whenever you use you’re keyboard to continuously repeat a command, like flaps down, and you turn an autopilot knob with the mouse for example.


Even if the first delay was a simple miscommunication, you cannot defend the delay to World Update 4 that was quietly revealed in the last blog post. It’s yet again another example of the Asobo team not sticking to promises. These are facts not opinions.


While I understand folks feeling disappointed that the fix to this issue is delayed a bit longer, I don’t understand at all the more melodramatic forms of outrage I’ve seen in various places. Anyone who has ever worked on a software product of more than moderate complexity knows that new features and bug fixes can have bug tails - especially something like a change to the core input handling code for the entire sim, that crosses all controller types and configs. It’s extremely easy to imagine finding out, upon further testing of the fix that was said to be “done”, that there are new issues or corner cases discovered or uncovered, or just even a general nervousness that input testing needs additional beefing up with more tests that didn’t exist before, to be sure your fix is fully verified and validated. It’s how software development works.

I’ve worked on moderate to very complex software projects, and these are all very plausible and reasonable reasons for delaying ANY non-trivial change a bit more. I wish the folks that don’t have that experience would trust those of us who do, instead of attributing it to malice or worse on the part of Asobo or Microsoft. Alternatively, if one chooses to be one who is going to rant about a feature or bug fix not making it into a given release, don’t be one of the ones then ranting about problems in that area that then need hotfixing because they released it too soon. You really can’t have it both ways.


The problem isn’t just this one example.

The problem is that this is another example of several over the last 6 months. No one here can fully trust anything that Asobo promises because of their track record. Rather than blaming the user for not being understanding enough, perhaps Asobo shouldn’t over promise and under deliver over and over again.


If this bug had been identified only a month ago, I would agree with your take regarding timelines and development processes. The criticisms have a mix of “you’re just getting to it now?” in addition to the “now that you’re getting to it, it’s taking too long”. The latter criticism is questionable, but the former criticism I think is very fair.


Sure, that’s arguable - put 10 reasonable people in a room with a list of bugs and you’ll come up with at least 11 different ideas for prioritizing the work. I don’t think it’s automatically and obviously awful that they haven’t fixed this yet, given the other sorts of bugs they do fix (with the reminder that no, there is probably zero overlap between the people that are giving you pretty stuff in World Updates and the folks working on the core mechanics in the sim) … but sure, I’ll be happy when it’s fixed as well. Having a Stream Deck has allowed me to avoid the worst of the issues, so I can understand why others are frustrated. I just wish people stayed realistic and respectful - this forum overall is short on both on occasion …


If by “the delay to World Update 4” you mean the fix being moved from Sim Update 3 to World Update 4, then this was communicated in this very thread by Jummivana ten days ago, apparently as soon as she learned about it. We have not heard why it was moved, but a sensible guess is that testing revealed issues needing time to be sorted out, so they had to choose between this and an further delay of Sim Update 3.

If, as I suspect, you mean the latest postponement of the expected release of Sim Update 4 by a week, what could be less “quiet” than an official blog announcement also explaining the reasons why?

The above are opinions based on known facts and a few assumptions.

NIce and informative post. I guess we’ll have to wait and see what Asobo come up with.

But why would anybody want to change the 2 vs 4 states behavior of the Alpha (and Bravo)? Is there anything you cannot do with the current implementation?

1 Like

Except the simply little fact that this hardware was marketed by MSFS as a partnered product that will work out of the box. How does the user experience match the MSFS/HC marketing video below …

Sold as working fully.
Does not work as sold.
Ignored by Asobo for months.
Third party work-arounds pushed as ‘solutions’
Finally acknowledged by Asobo but nothing forthcoming

Is this how trust is fostered?

Maybe in your world, not mine.


The main advantage is solving this kind of situation where the game you’re using the device with is not ment to receiving 2 inputs per switch change (one on and simultaneously the opposite one off)

For example I’ve tried using the Alpha on Project Cars II (why not using a -90/+90 yoke as a wheel!) and indeed I couldn’t assign switch inputs because of this.

It just makes sense to be able to have a switch alternating 2 states instead of 4 in some cases, and it isn’t hard to do via firmware changes or better, via firmware operating mode selection which you choose when powering up the device in pressing a combo of keys (this is a common low level firmware mode selection method).

In practice, it is easy: since each switch position is 1 or 0, it just takes disabling all OFF switch states as if the switch doesn’t exist at all. In other words, take a light switch for illustration (I don’t have the exact numbers in head but there are 2 buttons input per switch I’ll reference as button 10 and 11 below):

Current 4 states firmware mode:

  • switch down sets button #10 = 1 and button #11 = 0
  • switch up sets button #10 = 0 and button #11 = 1

Alternate 2 states firmware mode:

  • switch down sets button #11 = 0
  • switch up sets button #11 = 1
  • the hardware never make a button #10 visible to HID, or if not possible, let button #10 be 0 always.

Although this would give some more possibilities to use the hardware with other software, this won’t solve the “constant” input triggering FS2020 to accelerate the knobs because this is a FS2020 only bug (limitation to keep this post politically correct but it is a game design error in any way you see it).

I’m yet to try the Alpha on XP11 to see how they are mapping the switches there and see what it gives.

Okay, now I get it. Thanks.

You’re misinformed.

Jummivana communicated when it was moved from World Update 3 (as implied by “next update” from the dev stream in January) to Sim Update 3.

There was a line at the very bottom of the dev update last week that said that this bug will be fixed in World Update 4. This is the issue here. It’s now been delayed twice even though in January the devs said it’s fixed… why delay it so long if it’s fixed!?


OMG please this better not be true. That is absolutely ridiculous and a poor show from them if it is!

1 Like

There’s an unending smorgasbord of new bugs and instability issues that have finally been acknowledged by Asobo since WU3. It’s likely that many of those issues were deemed more critical by Asobo, thereby delaying the heading/OBS 10 degree bug fix to WU4. Not disagreeing with you, though. It seems to me (as a software engineer) that the endless bugs are not a result of bad faith from the dev team, but instead that they’re just wildly under-resourced (and we all know Microsoft isn’t going to spare any resources). After spending $3500 on a home cockpit setup and $120 on a broken piece of software, I promise I’m just as frustrated as everyone else. We’re just going to have to wait until all the issues are worked out, and that’s going to be a while…I’d speculate probably 6-12 months minimum. Until then, XP-11 with REP is probably your best bet for study-level aircraft.

Why don’t you just read what Jummivana wrote above? It’s post 220 or thereabouts. And then tell me who’s misinformed.

As for the original “promise”, I’ve watched the stream twice, and I never got the impression that it would be in WU3, but in SU3. Maybe that’s because I knew that World Updates were never supposed to include bug fixes or new features, only new world content. That, and the fact that Martial is probably more focused on Sim Updates, given his role in Asobo.

Please show me where Jummivana mentions a move from WU3 to SU3. It’s likely that she has tried to clarify that it was SU3 from the start, though, once the misinterpretation of Martial’s announcement began to spread.

I went back and checked the stream once more, and Martial’s words were that “it is fixed and should be part of update 3”. Notice the crucial word “should” and no mention of a “World Update”, or “next update”. It was, understandably, interpreted as WU3 by many, but that was certainly not what Martial said.

The stream is tagged, so it’s super easy to find the exact place near the end of it.

When Martial says something is fixed, I’m sure he means that a programmer has reported it so, but that doesn’t mean that it has been tested and declared ready for release.