Heading Increment Bug (10 degree instead of 1) Explained

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.

Scenery updates - with the exception of issues like terrain spikes in popular PG areas - should be sidelined entirely until the dang aircraft functions like it’s supposed to. What good is pretty scenery if you can’t tune your VOR or heading bug correctly?


This bug has been around for so long I doubt even WU4 will fix it. Given their past track record it’s hard for me to trust anything being said anymore, especially when we’re supposed to read between the lines to understand what they actually meant.


Could not agree with you more :wink:

Agree. And the HC hardware works perfectly in XP11, no convoluted work-arounds.



No sense building the roof until the walls are standing.


They might have found a regression bug during testing further delaying the release of the correction, or they might also have been unable to merge the correction to the release branch because this also can take a few days when there are many merges outstanding.

If you want to give this a chance for the next Q&A though:
Live Dev Q&A: Guided Question - #14 by CptLucky8

(the 2nd item in this post is about the 10 increment bug)

1 Like

Check post 174 as well… the chain of events is exactly what I am saying. Jummivana first says WU3 → SU3 then says SU3 ->WU4. When a dev says in January that the bug is “fixed” it should NOT take until April at the earliest to push out said fix.

I hope you can understand my frustration as I have been asking and waiting and waiting more for devs to update this since September: September 10th, 2020 Development Update - #16 by CalmEspresso


In post 174 Jummivana only confirms that my understanding of Martial’s words was correct, i.e., Martial meant SU3.

You still haven’t shown me anything to support your claim that Asobo promised the fix in WU3. It was a widespread misunderstanding for which, of course, Asobo is partially to blame, but it was never their intention to communicate that. And Jummivana clarified it the very next day in post 174. The rescheduling from SU3 to WU4 was also communicated openly as soon as the decision was made. So was the recent delay of WU4, btw.

I do understand your frustration and impatience, because I share it 100%. I have both the Alpha and Bravo sitting here waiting to be set free and show what they can do for me. The difference is that I don’t believe that there is any negligence, mischief or deceit on the part of Asobo involved. Plans change for a myriad of reasons that we can only speculate about, and this time it hit us.


Completely agree. For sure Asobo is working on it and they would have released something if it was fixed. So I’m also pretty confident that the solution will come.

And yes it is frustrating that we have to deal with this bug for now, but with the MSFS Mobile Companion (flightsim.to) it’s easy to come around.

This may well be true, who knows.

‘Fixed’ is funny word isn’t it. It might mean one thing to a programmer and another thing to the customer.

Customers will hear ‘fixed’ as in ‘that problem has gone away’ or, at best, ‘that problem will be gone after the next update’.

Are we to interpret ‘fixed’ as “the programmer says he has tweaked code. It has yet to be fully tested. It might not cause regression bugs. It has yet to be merged into the build. It has yet to be scheduled for a specific update or hotfix and is not, yet, a release candidate”?

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.

Should we all try and interpret what Martial actually means or take him at his word. Communication is a definate issue and I posit that it is Asobo/MS’s job to translate developers lexicon so the wider community fully understand the intent and proposed actions and to do this without any spin.

Everyone can make errors, and MARCOM can’t always tame the enthusiasm of a developer solving a bug!

I’m glad he said they’ve fixed it in the Q&A because it tells they are both listening and working on our reports, but I agree with you too it might have given a false impression to some customers wondering why such delay then.

Nevertheless, the most important thing to me, of all, is that they are proactive and they are considering customer feedback.

I understand your stance but I do not share it, personally.

Reading your posts (widely) suggest that you are personally and intellectually highly invested in the sucess of this sim and, being technical, you want to be part of that journey. Please forgive my pressumptions but I think it fair to say you see the sim in a deeper and wider context than most. Without meaning any insult (I really mean that) not all of us want to ‘nerd’ out (I am the biggest nerd going in other arenas, I do not use the word as a perjorative).

Most people, I think, view the sim as a part of something wider - gaming or aviation. My point is your patience is likely to be greater (perhaps better informed) than could reasonably be expected of a simple customer. Please take no offense, I’m kind of picking on you to make a wider point.

The handling of the 10 degree bug does not leave me feeling the team have been proactive nor that they are considering customer feedback. I do feel a pretty major issue with the sim has been ignored for a very long time and is now being handled badly.

I used to be an avid simmer but now I’m trending towards other pursuits, XP still satisfies and does not cause me issues with peripherals, updates etc (enough to say it is stable). My point is, I’m unable to give Asobo my confidence because that takes time and work… I’v other fun things to do.

Simply put and to be taken in the broadest scope, I gave them a fair chance but they have not won me over and my patience is being depleted rapidly.


I thank you for your kind words! :slight_smile:

I understand the frustration and believe me I’m communicating about this when I’m given the opportunity. Nevertheless even if this comes late since release and they didn’t do as much before, they are now at least certainly listening.

I also know for a fact forum moderators and community managers, like @Jummivana, are trying harder everyday identifying the most pregnant problems so that they can prepare digests for the developers, but I also believe one of the issue is the shielding between the customers and the developers. On one hand it is necessary otherwise they’d spend whole days reading the forums, and this is why there is the vote system and Zendesk to help. However this process is most likely confronted to the overall game design decisions and product positioning, and this is where I sense the most communication problems sometimes. Whatever our reports, whatever how representative the digests, if this doesn’t match the vision, it won’t go far.

To illustrate this point, take this topic:

From a consumer point of view, the Honeycomb is not working with FS2020. They blame the hardware which is disrupting FS2020. Should they plug the hardware to XP11, they’d realize it is working fine, they’d then blame FS2020 not handling the hardware as good as XP11. Then you have community managers digesting customers griefs, and finding this topic. They pass the information along because it is starting to accumulate lots of votes, but who to blame then? Who will take upon his/her shoulders from both sides figuring out which product is doing it wrongly? Especially more so if both Asobo and Honeycomb did work together early on, in deciding what each product would do with the other: FS2020 is providing the “_SET” events which can be 0 or 1, and Honeycomb is delivering a switch state which can be 0 or 1. What is wrong with this?

And here comes the bulk of the problem: who has enough horizontal understanding, as well as enough vertical understanding of these matters in both teams? Who could coordinate all this? Who on these forums has enough knowledge about all this to figuring out the problem and digesting the information so that it is useful to the developers?

Honestly, I know this controller input problem for ages (see, my answer is post #2 in this topic). It is the clear root cause of this issue. But having acquired an Alpha yoke recently, I also see how Honeycomb implementation could be misleading with an unusual 4 states 2 positions switch.

This implementation makes perfect sense in order to make sure no external event would trigger a logical switch position which would then disagree with the physical switch position, but again, this is not necessary either. I’ve documented how this might not be a good approach from a logical standpoint in that they could instead just poll the logical state and make the changes when it disagree. But this would require Honeycomb building an add-on to FS2020, and FS2020 supporting such kind of add-on in the SDK.

There is no one size fits all method here, but there are methods which are not over stepping the toes of others. It is not dissimilar to the CDI/NAV issue when adding a RXP GPS in an aircraft: most aircraft code logic is not coded with external control in mind and they enforce the CDI/NAV mode based on their own local variables, so that an external GPS can’t override this, instead of changing the internal simulator mode state ONLY when the user is interacting with the mode (aircraft → sim) and changing the local state variable only when the sim is changing the mode (sim → aircraft).

As long as every product is implemented with the view he is the master of the controls and the state, and as long as the SDK is enforcing this vision because of the lack of clear guidelines and architectural principles supporting this vision, you’ll face the same problems every time in my opinion. And here I must agree with you, the game design decisions are certainly very good from the point of view of a product, but I’m very confident I don’t share the same point of view about positioning it as a platform, and my experience in this field over 2 decades dealing with such matters is certainly giving me a different and transversal perspective view which might not be unique but rare, I agree. It is not better, just different because I have a habit of dealing with such questions.

So what to do? (because it is one thing to rant, but it is better offering solutions isn’t it?)

Very simple to me:

  1. Cure the bug in FS2020 because it is a bug first and foremost, a logic bug in the handling of the acceleration feature.

  2. Then for Honeycomb, because it can’t just be used for FS2020 and XP11: offer an alternate mode via firmware flashing, or via a new dual-option firmware so that you can choose which mode you’d use without the need to flash every time. This would be a good starting point solving both problems in my opinion. This shouldn’t be addressed via a driver or a service running in the background to me.

  3. if enforcing the switch position and the logical state position is paramount for whatever reasons, this should be solely handled by software at the simulator and user level. In other words, and this is the 3rd step in FS2020 revising the control input system: provide scriptable and universal input handling. This means relegate to the past the antiquated FS5 area SDK consisting in ENUM and ID. Instead, make any event a clear named event (a string) like in XP11 so that both FS and add-ons can publish their own. Make these interceptable like in XP11 too at the SDK level so that add-ons can intercept, change, and pass along or block incoming events. Go the extra length compared to XP11 to also let user overriding the events via scriptable code (LUA for example), so that any such logic could be serviced directly at the user level so that he/she can adapt and fully tailor the hardware to the software.

I’m by no mean no authority about all this, and I’m not commanding anyone doing this, but this is how I’d do if it would solely depend on me. Because this is the type of implementation which separate a product from a simulator platform to me.

Other references and materials:
About the Asobo/Honeycomb input handling solutions
About the Firmware Idea


You should take him at his words, but be sure to put them in the right context. He said it in a stream titled “Developer Q&A”, after all.

I’m a professional developer myself, so I guess that’s why it was so obvious to me what Martial meant. But not everybody is, so misinterpretations by laymen of what is being said in these streams is to be expected.

The alternative is that all communications to the public go through some kind of Public Relations filter, and that is something I would be very sad to see happen. Given all the heat they take in these forums no matter what they say or don’t say, I wouldn’t be surprised if they became more reluctant in the future to share inside information with us, though.

For me, The stress for all peapole is becose the update is too long for fix somes urgent bug…
Xplane team maybe 15… asobo 300…?

Why its no possible to fixe major bug in little patch , why waiting only big patch 10 GO for another problem…, just launch and use little correction the same of xplane… i cant belive 300 peapole for asobo vs 15 xplane … just for graphics?

Honestly change rotation plz, 295 for bugs and beter avionic and 5 for graphic now…
Its normal its free mod from the community corrige for better movement , better flight for all plane? serious, ?

Make patch more quickly and use another copy of msfs with alpha patch for user test it before launching for all players…

Correction major bugs more quikly = forum clear and happy to waiting for try to playing normaly with strong investisment

10° to 1¨° need to be fix. no excuse for make it correctelly
if im boss from asobo, and i have programmer make the problem inside my simulator, go school for learn programation and bye… the peapole here its no childrens but i reapeat 40years and real pilotes

MAny Peapoles here buy expensive computer with Graphics card ! 3080/ 3090 ^^ for just try 30 min and stopping…
I hope seriously the effort in next patch for the serious simulator.


can teach how to do that?

Thanks for your in-depth and thoughful reply, it is appreciated.

I am quite sure there are many individuals from MS, Asobo and the partners who are diligent and forward thinking. However, these individuals do not seem to be operating within a cohesive organisation. I hope the eco-system and commercial culture improves. I am going to leave my comments at that becuase frustration is not to far from breaking through.

Currently, I have no choice but to abandon MSFS. WU3 download loop has made it impossible to update … Yes I have followed each and every suggestion (not to mention being network savvy).
The download/update issues make it impossible, for me, to both manage the sim and fly it - time is valuable :wink: Since thursday, I have downloaded for 47 hours straight (loop, loop, loop) and this is not tenable - it is frustrating, eats data and I need that PC for other things. Given the rate at which updates are being pushed this adds up to a lot of time, effort and wasted bandwidth.

I’ll come back to it in the Autumn and see what the state of play is. Luckily, I am pragmatic enough to try again and realise the network problems I have specifically are an edge case. I could live with bugs, but if you can’t run the sim it is time to give up.

While my entire experience of MSFS has been negative I do know many many people are enjoying it and it will, probably, settle given time. I do hope so, and in the meantime I hope everyone gets enjoyment from the sim, be that flying or developing.

Good Luck :wink:


Thank you for your kind words!

SU3 is around the corner, maybe resolving these problems in a few days from now. Maybe this will be enough to keep you trying just a little more prior giving up?

1 Like

Actually found out, that the engine switches cause this at the TCA quadrant.

1 Like

Its still broken in sim update 3.