Please allow me to explain why this is not explaining anything and why this is not solving the issue.
-
This 10deg increment bug is well known and well documented since at least 2004 (I’ve posted links to a few topics at avsim talking about this as an example). I remember perfectly well this problem back in the time and this was raised during FSX Beta and never acknowledged for nor corrected*
-
I believe (but I might be wrong) FSX-SE did correct this problem, and/or Prepar3d and probably not until P3D2 maybe (but I might be wrong too - I lost track of these).
-
If Honeycomb code is continuously sending their ON or OFF position state this is wrong too, and this is actually this kind of coding practice which is causing a lot of grief among simmers trying to mix different products together, like the RXP GNS/GTN with third party aircraft which gauge code does the same internally.
.
The “proper” way to code this sort of things to me is in the form of changed states, not absolute states. In other words:
a) read FS simvar value
b) if simvar disagree from your switch position, send a command to rectify.
.
Nothing more is needed, but because of the actual FS2020 SDK logic which is nothing else than the FSX SDK logic, and because this implies this implementation can only be done via polling for most of the monitored simvars, there could be a short gap between the state change in FS and the command issued by the hardware driver, which leads me to the next point: -
Asobo seems to be working mostly with a few Aircraft vendors and is putting them in the position of teaching Asobo how are the third party developers doing their aircraft in FS specifically. Because aircraft developers have limited exposure to the questions pertaining to inter-gauge/inter-vendor interactions because the aircraft is a whole in the FS SDK world, this gives little change to Asobo getting much expertise about these practical questions other vendors are confronted with daily for their products.
.
Furthermore, in working mostly (if not only) with aircraft developers doing FS products, this shuts the door to learning how the same things are better done in other simulators and therefore how FS2020 could benefit from doing differently. And this makes me revising point 3) above:
.
in XP11 for example, you can intercept commands and dataref state changes so that the “short gap” I was mentioning would be inexistent: the moment the state change, the hardware driver would immediately send the command to restore the state matching the hardware switch.
As a conclusion: there are two disconnected problems with the Honeycomb hardware and FS2020 in my opinion:
-
FS2020 is not accelerating event inputs per inputs, but globally, which is wrong. Only the ones repeating should be accelerated, all others shouldn’t be affected.
-
Honeycomb driver is trying enforcing the FS2020 state in sending a stream of events, instead of just sending the event needed to make the simulator state matching the hardware state when both disagree.
Both of these problems are independent of the other: Asobo should correct the implementation details of the acceleration system because it is problematic with or without hardware, and Honeycomb should correct the implementation logic so as to not hammering the simulator with non-stop events (for nothing 99.9999% of the time when no hardware switch changes position). At least, Honeycomb could easily implement a user selectable implementation: “Enforcing” (the current one) and “State change” (the proposed one).
*This shows how much FSX logic and SDK is still rooted in FS2020 in the sense instead of rethinking the simulator outside the box, the chosen path of taking the FSX code base and its SDK, removing what is not good and keeping what is good only works if you do have the knowledge about what is good and for this knowledge, you rather talk with a wider audience of 3rd party developers than just a select few.
PS: I feel compelled explaining a little more the little “rant” I’ve written just above in italic about the SDK. I strongly believe Asobo is doing a superb job with everything non gauge/system related in the SDK. It really shows new structures and logic, new implementation and modern interfaces and tooling. However, for everything gauge/system/modules, it is nothing else than FSX SDK in worst. Worst because not all is working yet, worst because the same bugs and limitations are therefore still there, worst because you can’t even re-code the deficiencies of the simulator because of the sandboxing approach depriving 3rd party vendors from enhancing the simulator internals. I find this a waste of energy trying to perpetuate these antiquated concepts inherited from the FS5 age and dating back from than 20 years.
.
For example, Asobo has built a solid JS/HTML system which really has deep capabilities for 3rd party developers, and this system is based on revolutionary concepts internally. Yet, they spend energy trying to “bridge” this with the antiquated constructs of the past so that 3rd party vendors can “easily port” their existing code… I’d rather them saying to us: “if you want to do an add-on, you’ll have to redo your code. We’re offering the choice of a future proof object oriented construct you can expand upon, or, a very low level down-to-the-entrails C++ access to the most basic internal structures. If you want anything which resemble the older SDK so that you port your aircraft faster, you’ll have to do it yourself.” The same reasoning makes me still wondering why it is they want to implement a XML gauge bridge into FS2020. Sure it will help porting existing XML gauge code, but why not just directly use the JS/HTML code path, ditch the old stuff and technological debt and let FS2020 fly higher…