I have been testing this with the Complex Twin settings for the Baron. Only things assigned to the Alpha is the Axis’s and buttons that are on the yoke having to do with Views and Rudder trim. On the Bravo it is just the Axis’s, Flaps and A/P controls. All other buttons and rocker switches set up in Gremlin.
That is not the bug. The bug is not caused by the Honeycomb hardware. The bug is triggered by the Honeycomb hardware.
And if you claim to have solved the bug, then why can i still easily reproduce it on my machine?
1 Like
Yes that is the bug. There are buttons in a constant activated state, Alpha or no Alpha, and it is this “on” state that triggers the acceleration, ie the 10-degree changes. This removes the on state, and the bug is removed. Gone. Fixed. And you are now arguing semantics and I’m just not interested.
Okay. Don’t give up, I’ll send you a profile at some point in the next day or so. I will post it here.
You have not fixed the bug. I am still having this issue. A lot of other people here still have this issue. You have made no code changes to the simulator, and thus the issue is still there.
This whole thread started as a way of understanding what the bug is and how it works. Everyone here is waiting for a bug fix. You coming up with a workaround and proudly announcing that you fixed the bug when you did no such thing is not helping anyone and is creating confusion. I don’t see what your problem is with simply admitting that it’s a workaround? With your spurious claims should we tell Asobo to stop working on this cause you fixed it?
So unless you can give us all a patch for flight simulator that fixes this bug such that sending a constant on signal to the sim doesn’t cause input repetition in unrelated controls, you have not fixed any bug.
Stop making confused claims. People are waiting for Asobo to fix this, despite any existing workarounds. That’s all i’ll say on the subject.
1 Like
This is getting very confusing!!! I have the Honeycomb Alpha and I still have the 10 degree bug!
So is it Asobo bug or is it honeycomb bug???
My simulator works. Yours doesn’t.
Ask me how much I care about semantics.
2 Likes
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
3 Likes
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 
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
2 Likes
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?