Community feedback towards developers

[CptLucky8]

@CristiNeagu

This is the disconnect people are talking about in multiple threads on this forum. I don’t think it’s done intentionally. It seems to me like the overarching issue here is that the method through which feedback is passed from the community to the devs is fundamentally broken.

This resonates a lot to what I’ve been posting in the past:

@CptLucky8

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.

Not long ago for SU3:

@CptLucky8

This one is fantastic!

Does it mean their interpretation of the 10deg bug problem was this bug in their code base and since they solved this bug in their code base, they thought they solved the 10 deg bug without actually knowing what it is we are talking about in these forums and therefore begging the question why we are loosing time reporting?

Or

Does it mean this is an unrelated bug they have corrected but the specific 10 deg acceleration bug correction is still not released and won’t be until WU4 or a hot fix in between?

I find this really really puzzling not in terms of not being able to correct bugs, but in terms of is there really someone able to comprehend the reports we send via Zendesk or via Topics with votes, able to understand what it is about, and able to translate this into technical explanation to a sufficient level so that developers can more effectively understand what it is all about.

I’m sorry to insist on this but I believe the 3rd party developers are able to cope with understanding the link between simmers feedback and simulator function, and this further strengthen to me the idea of the shared source approach I’m exposing for the next Q&A and which you can support in clicking the heart icon here:

Also on the LOD topic:

@CptLucky8

I honestly think they are not lying to us at all.

Instead, they are doing corrections to this bug, but I strongly believe, and I might be entirely wrong, the outcome is not what is expected only for a few possible reasons:

• Either they don’t have the actual feedback we do post here, or to Zendesk (I’ve been documenting these LOD ring distance problems since, well, way back last year)
• Or they do have the feedback but it is filtered out in such a way, because of the number of reports in these forums to digest and sum up, that the final “short description” of the problem is not matching the actual main issue we’re reporting
• Or they just can’t change much in the graphics code base, because the DX11 branch is stalling in favor of the DX12 branch and they’ll risk more breaking changes in trying to change the DX11 rendering code.

In any case, whatever the reason, I wouldn’t expect much changes to this, or night lighting, or some more, until at least the official release of the DX12 version, and I’m fine with this.

Especially because prior to that:

@gadwin777

Hi. So I was watching the Q&A today and Sebstian mentioned how he had difficulty tracking one of the bugs the community had brought up: https://www.twitch.tv/videos/784582715?t=01h00m17s

For this particular bug that Sebastian mentioned, CptLucky8 has done a nice analysis of what the problem is and I’m sure if Asobo find that thread, they will find CptLucky8’s thread with CptLucky8’s analysis.

However, I have also read a lot of other threads, even threads in the Bugs & Issues forum, where people report a bug but aren’t giving Asobo enough information to reproduce the bug.