I understand your stance but I do not share it, personally.
Reading your posts (widely) suggest that you are personally and intellectually highly invested in the sucess of this sim and, being technical, you want to be part of that journey. Please forgive my pressumptions but I think it fair to say you see the sim in a deeper and wider context than most. Without meaning any insult (I really mean that) not all of us want to ‘nerd’ out (I am the biggest nerd going in other arenas, I do not use the word as a perjorative).
Most people, I think, view the sim as a part of something wider - gaming or aviation. My point is your patience is likely to be greater (perhaps better informed) than could reasonably be expected of a simple customer. Please take no offense, I’m kind of picking on you to make a wider point.
The handling of the 10 degree bug does not leave me feeling the team have been proactive nor that they are considering customer feedback. I do feel a pretty major issue with the sim has been ignored for a very long time and is now being handled badly.
I used to be an avid simmer but now I’m trending towards other pursuits, XP still satisfies and does not cause me issues with peripherals, updates etc (enough to say it is stable). My point is, I’m unable to give Asobo my confidence because that takes time and work… I’v other fun things to do.
Simply put and to be taken in the broadest scope, I gave them a fair chance but they have not won me over and my patience is being depleted rapidly.
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.
You should take him at his words, but be sure to put them in the right context. He said it in a stream titled “Developer Q&A”, after all.
I’m a professional developer myself, so I guess that’s why it was so obvious to me what Martial meant. But not everybody is, so misinterpretations by laymen of what is being said in these streams is to be expected.
The alternative is that all communications to the public go through some kind of Public Relations filter, and that is something I would be very sad to see happen. Given all the heat they take in these forums no matter what they say or don’t say, I wouldn’t be surprised if they became more reluctant in the future to share inside information with us, though.
For me, The stress for all peapole is becose the update is too long for fix somes urgent bug…
Xplane team maybe 15… asobo 300…?
Why its no possible to fixe major bug in little patch , why waiting only big patch 10 GO for another problem…, just launch and use little correction the same of xplane… i cant belive 300 peapole for asobo vs 15 xplane … just for graphics?
Honestly change rotation plz, 295 for bugs and beter avionic and 5 for graphic now…
Its normal its free mod from the community corrige for better movement , better flight for all plane? serious, ?
Make patch more quickly and use another copy of msfs with alpha patch for user test it before launching for all players…
Correction major bugs more quikly = forum clear and happy to waiting for try to playing normaly with strong investisment
10° to 1¨° need to be fix. no excuse for make it correctelly
if im boss from asobo, and i have programmer make the problem inside my simulator, go school for learn programation and bye… the peapole here its no childrens but i reapeat 40years and real pilotes
MAny Peapoles here buy expensive computer with Graphics card ! 3080/ 3090 ^^ for just try 30 min and stopping…
I hope seriously the effort in next patch for the serious simulator.
Thanks for your in-depth and thoughful reply, it is appreciated.
I am quite sure there are many individuals from MS, Asobo and the partners who are diligent and forward thinking. However, these individuals do not seem to be operating within a cohesive organisation. I hope the eco-system and commercial culture improves. I am going to leave my comments at that becuase frustration is not to far from breaking through.
Currently, I have no choice but to abandon MSFS. WU3 download loop has made it impossible to update … Yes I have followed each and every suggestion (not to mention being network savvy).
The download/update issues make it impossible, for me, to both manage the sim and fly it - time is valuable Since thursday, I have downloaded for 47 hours straight (loop, loop, loop) and this is not tenable - it is frustrating, eats data and I need that PC for other things. Given the rate at which updates are being pushed this adds up to a lot of time, effort and wasted bandwidth.
I’ll come back to it in the Autumn and see what the state of play is. Luckily, I am pragmatic enough to try again and realise the network problems I have specifically are an edge case. I could live with bugs, but if you can’t run the sim it is time to give up.
While my entire experience of MSFS has been negative I do know many many people are enjoying it and it will, probably, settle given time. I do hope so, and in the meantime I hope everyone gets enjoyment from the sim, be that flying or developing.
SU3 is around the corner, maybe resolving these problems in a few days from now. Maybe this will be enough to keep you trying just a little more prior giving up?
Hahah - not only is it not fixed, but now you can’t adjust by 1’s in the sim either. With an always on joystick bind, even clicks are now going by 10s.
Why it is not possible to use 1000/100 steps at ALTITUDE knob after this new update, tried in B747 and Cessna Citation Longitude. It changed of course, only hold the mouse button. A fast change starts you crazy
Thanks, of course, as a matter of procedure I have reported the download loop on each and every update and implimented each suggestion on each update. The canned responses have all been actioned, despite being entirely generic.
I only referenced the download loop talking to @CptLucky8 but I have spent a lot of time tracking down the issue (as I experience it) and have reported, at length, to Zendesk - only to recieve another duplicate canned response.
I could write pages on this subject but this thread is about 10 degree bug.
Since thursday, I have downloaded for 47 hours straight (loop, loop, loop) and this is not tenable - it is frustrating, eats data and I need that PC for other things. Given the rate at which updates are being pushed this adds up to a lot of time, effort and wasted bandwidth.