Sometimes 1 but most times 10. I didn’t think that was related to the gear level though, unless I misunderstand your original comments.
Really interesting! I’m currently using axis and ohs and the bravo and (with help) have got the altitude working with the rotaries and a bravo physical switch to select between 100 and 1000 - do you think I could use similar logic you’ve used here with virtual joystick to fix the heading bug 1/10 issue but with AAO?
I’ve not used AAO so I couldn’t really say if it works the same way. It couldn’t hurt to try it though.
PLZ WERE IS THE SOLUTION increment bug heading 10 to 1 for assign in my QGMC710 !
5h i try all, i del all profil for assign only bug hdg
but its only 10° !!!
i search on forum etc… any solution?
ASOBO plz MAKE ASSIGN BUG 1° in command setup and its great !
Wath is the solution after 6 month with the same problem
I do understand that development and testing takes time, but in the last Q&A Sep was very positive about this bug. To me and I guess quite a lot of people, it sounded like its done done, not in testing phase.
Maybe talk to the devs so people dont except this much and become frustated like me now. (
I received my Bravo Throttle yesterday and tried it out today, its brilliant, but now I need to do everything new since this bug is postponed and I cant fly like this for over a month)
PS: World Update 4 is also delayed
this works perfectly
and once you understand the concept of Joystick Gremlins condition paramater you’ll probably stickn with this solution as it’s so flexible
Actually, it was Martial, not Seb, and I believe he’s the guy in charge of all the programmers. When he says something has been fixed, he most likely refers to feedback from the programmer assigned to the task. It’s true that all three of them gave the impression that we could expect it to be in Sim Update 3, so clearly that was the plan at the time.
But who knows, maybe testing revealed side-effects that had to be addressed too, or maybe they just didn’t realize at the time how many things would have to be tested on various controllers.
The bottom line is that plans are often changed by necessity in the software development industry, and Jorg, Seb and Martial often repeat that schedules may change over time.
The latest delay is a result of an huge slip-up in WU3, combined with the widespread hysteria caused by it. Nobody could foresee that.
BTW, I also received my Bravo yesterday, so I know where you’re coming from.
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.
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”
- 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?