Has Asobo made any mention of addressing this situation? The one mention of a “heading bug” was actually addressing something else according to their last live stream. I can’t believe this is that difficult to fix.
1 Like
Actually, they said that it would be included in WU4, but the latest Developer Update only says “2021”.
There has been so much confusion about which error they were referring to, that I’m becoming unsure that they fully understand what this thread is about and what the consequences of it is for us.
All the fuss about performance hit in SU3 has probably thrown most of their plans up in the air, too.
4 Likes
The 3-18-2021 Feedback Snapshot says the "Heading Increment Bug (10 instead of 1) ‘Mouse Interaction Fixed’.
So, what the heck does that mean? What about keypress interaction?
1 Like
I skimmed this thread but didn’t read everything carefully. So if this detail has already been discussed then I apologize for duplicating.
Today I started using a keymapping software after seeing a youtube video from Overkill about a possible fix to the increments. Through a couple hours of trial and error it seems the bug is tied to the Gear Down command for my Bravo Throttle when set inside MSFS controls. If I set Gear Down to a keyboard command and then assign that command to my gear lever through RS Mapper instead of MSFS, then the increments work correctly. I don’t know if this is a coincidence or an actual solution for the Bravo or other throttle quadrants, but it seems to work for me.
I’m not sure either, but I presume “Mouse Interaction Fix” is the one Martial referred to in the 5th Developer Q&A when he claimed that “it is fixed” and would be included in “the next update”. Everybody here took it as the bug discussed here. (Often referred to as the “Honeycomb bug”, although it affects all controllers with persistent switches of various kinds).
A few days later Jummivana regretted to inform us that the fix didn’t make into SU3 but would be included in WU4.
In the 6th Q&A (the latest one) Martial apologized for the confusion, but I don’t remember him saying anything about changed plans, just that he had mixed up the two issues in his previous announcement.
So we all thought WU4 remained the target, but this latest update just adds to the confusion, and there really is no way to tell if we should go ahead with some workarounds or wait for WU4.
@Jummivana, do you have a status for us?
2 Likes
The conversation went a bit like this:
“How’s it going with X?”
“Yeah sorry, I mixed up X and Y last time”
“Oh ok thanks!”
Everyone else: “Yeah but how’s it going with X??”
1 Like
Either way, we will find out soon. I just hope the Honeycomb or ‘always on switches’ issue is finally resolved.
did you check the macro with the integrated input monitor in joystick gremlin? does the mapped vjoy button 13 also stay switched on there?
if not … I would suggest doublechecking, that the switch-position is indeed nowhere mapped anymore in the active MSFS profile.
could be a conflict reason.
I don’t know if is related or not, but I managed to solve it by remapping left bravo knob. I remove it from selection X mapping in FS2020 and set it as a condition in Joystick Gremlin.
After that now I have 1 degree increment an 100s fts increment.
Just curious, why is Asobo saying the mouse control is fixed when I use the mouse (either clicking or scrolling with mouse wheel) I still get 10 degree/ 10 kts increments. Are they aware of what they’re saying? I’m confused.
In my case, I experience 10 increments when parking brake is set and 1 increments when parking brake is released, even in flight. So, I sometimes exploit it by setting the parking brake in flight just to turn the knob faster when the bug is way far.
Yeah, one begins to wonder. But, my best guess is that the one they say they have fixed had to do with a general acceleration issue that I was not aware of. But for those of us suffering from the “Honeycomb syndrome”, it made things even worse.
If I understand this thread correctly, everyone is experiencing the same issue I am…that is try to follow ATC that says to level out at 3500 feet, but I can only adjust in increments of 1000 feet.
One more question: I thought this was a new flight sim from the ground up. How is it then that there is a “bug” in the code that has long been known since FS9?
It is a new sim in many ways but not entirely. Much of the sim is built on existing code.
I think it makes sense to use existing software where it is practical - if there is no need to re-invent the wheel why do it? But it’s an absolute joke that issues like this still exist when they were initially reported early on in the alpha testing stage of the sim. Especially when the issues are acknowledged in Q&As and said to be “fixed” but then pushed back like this has been…
Don’t get me wrong I am a big fan of MSFS but I think the priorities are around having an entertaining game rather than a useful simulator; and I really wish it was the other way around
1 Like
Well… not quite… From what i can see, the goal is having a simulator with training wheels. They go to all these lengths to simulate weather and flight dynamics, then they dumb things down to make it more beginner friendly. It’s a bit of a confused approach. If they were aiming for an entertaining game, at least they’d be clear on what they’re trying to achieve.
Good point. It’s just hard to understand why they would ignore practically game breaking bugs like this where anyone using peripherals (which many serious simmers do) need to buy 3rd party software to get around these issues, but they put a lot of resources into visual updates to make buildings etc look better in certain parts of the world.
I guess there is a certain push for both a useful simulator as well as a pretty game, but still I wish it was more focussed towards the practical side
Whilst it is annoying, it’s not game breaking. There are workarounds.
No they don’t… i could never quite understand this weird obsession people have with FSUIPC. Seems to date back to FS9 days or earlier when controllers were quite basic and were using generic drivers. I never had a need for it. Saitek’s default configuration software was more than enough to assign any controls i wanted on my X52. Thrustmaster’s Target software is a full blown programming language. No one needs FSUIPC to assign controls. Use the software that comes with your controller.
1 Like
You still agree that you need to use 3rd party software to configure controls rather than using the controls in MSFS which I believe is not acceptable.
You said they are making it beginner friendly which I think directly contradicts the need to use 3rd party software to configure basic controls
But you don’t need to buy anything. And besides, you have to use that software anyways to unlock the full potential of your hardware. That’s why it’s not a game breaking bug. But yes, they should definitely fix this.
- There is nothing contradictory about this. Being a beginner in flying doesn’t mean you’re a beginner in software too.
- You’re not talking about basic controls. You don’t need any other tool to configure basic controls.
Look. It’s a bug. It’s annoying. It’s inconvenient. It has to be fixed. But there’s no need to exaggerate how bad it is.
Why do you need 3rd party software to use the full potential of a simple peripheral controller? I certainly don’t need that for mine. It is definitely not beginner friendly to require users to use 3rd party software to be able to utilise a heading / altitude bug etc, that should be a fundamental part of the sim that can be used by anyone no matter what hardware they are using without the need for 3rd party software
It is a very simple bug that would have been extremely easy to patch in the amount of time they have had (from the start of the alpha until now) and yet they are still delaying the fix without reason. I’m not saying that is unacceptable, I am just saying I wish that there was more of a focus on this kind of thing rather than pushing so many of their resources towards visual updates etc
3 Likes