I understand the frustration and believe me I’m communicating about this when I’m given the opportunity. Nevertheless even if this comes late since release and they didn’t do as much before, they are now at least certainly listening.
I also know for a fact forum moderators and community managers, like @Jummivana, are trying harder everyday identifying the most pregnant problems so that they can prepare digests for the developers, but I also believe one of the issue is the shielding between the customers and the developers. On one hand it is necessary otherwise they’d spend whole days reading the forums, and this is why there is the vote system and Zendesk to help. However this process is most likely confronted to the overall game design decisions and product positioning, and this is where I sense the most communication problems sometimes. Whatever our reports, whatever how representative the digests, if this doesn’t match the vision, it won’t go far.
To illustrate this point, take this topic:
From a consumer point of view, the Honeycomb is not working with FS2020. They blame the hardware which is disrupting FS2020. Should they plug the hardware to XP11, they’d realize it is working fine, they’d then blame FS2020 not handling the hardware as good as XP11. Then you have community managers digesting customers griefs, and finding this topic. They pass the information along because it is starting to accumulate lots of votes, but who to blame then? Who will take upon his/her shoulders from both sides figuring out which product is doing it wrongly? Especially more so if both Asobo and Honeycomb did work together early on, in deciding what each product would do with the other: FS2020 is providing the “_SET” events which can be 0 or 1, and Honeycomb is delivering a switch state which can be 0 or 1. What is wrong with this?
And here comes the bulk of the problem: who has enough horizontal understanding, as well as enough vertical understanding of these matters in both teams? Who could coordinate all this? Who on these forums has enough knowledge about all this to figuring out the problem and digesting the information so that it is useful to the developers?
Honestly, I know this controller input problem for ages (see, my answer is post #2 in this topic). It is the clear root cause of this issue. But having acquired an Alpha yoke recently, I also see how Honeycomb implementation could be misleading with an unusual 4 states 2 positions switch.
This implementation makes perfect sense in order to make sure no external event would trigger a logical switch position which would then disagree with the physical switch position, but again, this is not necessary either. I’ve documented how this might not be a good approach from a logical standpoint in that they could instead just poll the logical state and make the changes when it disagree. But this would require Honeycomb building an add-on to FS2020, and FS2020 supporting such kind of add-on in the SDK.
There is no one size fits all method here, but there are methods which are not over stepping the toes of others. It is not dissimilar to the CDI/NAV issue when adding a RXP GPS in an aircraft: most aircraft code logic is not coded with external control in mind and they enforce the CDI/NAV mode based on their own local variables, so that an external GPS can’t override this, instead of changing the internal simulator mode state ONLY when the user is interacting with the mode (aircraft → sim) and changing the local state variable only when the sim is changing the mode (sim → aircraft).
As long as every product is implemented with the view he is the master of the controls and the state, and as long as the SDK is enforcing this vision because of the lack of clear guidelines and architectural principles supporting this vision, you’ll face the same problems every time in my opinion. And here I must agree with you, the game design decisions are certainly very good from the point of view of a product, but I’m very confident I don’t share the same point of view about positioning it as a platform, and my experience in this field over 2 decades dealing with such matters is certainly giving me a different and transversal perspective view which might not be unique but rare, I agree. It is not better, just different because I have a habit of dealing with such questions.
So what to do? (because it is one thing to rant, but it is better offering solutions isn’t it?)
Very simple to me:
-
Cure the bug in FS2020 because it is a bug first and foremost, a logic bug in the handling of the acceleration feature.
-
Then for Honeycomb, because it can’t just be used for FS2020 and XP11: offer an alternate mode via firmware flashing, or via a new dual-option firmware so that you can choose which mode you’d use without the need to flash every time. This would be a good starting point solving both problems in my opinion. This shouldn’t be addressed via a driver or a service running in the background to me.
-
if enforcing the switch position and the logical state position is paramount for whatever reasons, this should be solely handled by software at the simulator and user level. In other words, and this is the 3rd step in FS2020 revising the control input system: provide scriptable and universal input handling. This means relegate to the past the antiquated FS5 area SDK consisting in ENUM and ID. Instead, make any event a clear named event (a string) like in XP11 so that both FS and add-ons can publish their own. Make these interceptable like in XP11 too at the SDK level so that add-ons can intercept, change, and pass along or block incoming events. Go the extra length compared to XP11 to also let user overriding the events via scriptable code (LUA for example), so that any such logic could be serviced directly at the user level so that he/she can adapt and fully tailor the hardware to the software.
I’m by no mean no authority about all this, and I’m not commanding anyone doing this, but this is how I’d do if it would solely depend on me. Because this is the type of implementation which separate a product from a simulator platform to me.
Other references and materials:
About the Asobo/Honeycomb input handling solutions
About the Firmware Idea
