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.
