exactly this
speaking for the bugs that annoy me the most, those that ruin a long flight
i totally understand that a bug that reveals itself intermittently and only after a 3 hour long flight is an absolute nightmare to track down and reproduce
however! if your product is a flight simulator, then that kind of scenario will be unavoidable, you should anticipate that!
don’t just leave it unfixed!
the devs should take the higher road here
an insim bug tool sounds like just the thing, because with a bug like this you will have the tracking down done for you by the users!!
I know you mean well, but the drone camera was there from day one, part of the core sim, so definitely made by Asobo. As I said, it’s hard to understand.
And we have a new entry in the “won’t fix” family: ATC Not vectoring for approach won’t be fixed. At least the wording this time is “won’t fix at this time”.
ATC vectoring was working in FSX, so one has to wonder what the problem might be.
This thread was sent up to the Community team over a month ago, and there was no acknowledgement of it from anybody.
Now, Flight Simulator 2024 is on fire and maybe nobody cares about this anymore, but people should. If you log a bug report in the forums, maybe someone will look at it. And if you’re lucky, maybe someone will take the time to reproduce it, and if you’re lucky, maybe they will get a reproduction of the issue and log it. And then if you’re really lucky, maybe the development team won’t throw out the bug report a few years later as a “Won’t fix.”
Exactly. That’s been my problem with Zendesk from day one. “Solved” in Zendesk does not mean Solved. Absolutely the wrong choice of words there. It means one or more of many possible occurances, and is completely opaque to what happened. And it’s extremely frustrating to the person reporting.
Unable to reproduce
Duplicate bug → xxxxx
Sent to appropriate group for processing -? Do we get to know the result in the new place?
Unfortunately, we don’t have any control over that. It’s built into Zendesk that when the support agent closes a ticket, the system sets the status to “Solved”. So if you submit a bug to Zendesk and the agent logs it in our internal bug tracking tool then closes the ticket, you will see the status as “Solved” even if the bug itself hasn’t been fixed by the dev team yet. It just means the ticket is closed.
We’re aware this can be confusing to end users, but unfortunately that’s how the Zendesk software is designed. This is described in our Zendesk FAQ here:
I dealt with this at work, too. It makes sense to an IT team, but it’s very frustrating to an end-user as there’s no other indication or feedback that the problem was solved or is being worked on. And end-users don’t have the inside access to the dev managment process to see where things are at.
Yes, I know. I was only agreeing with @TOLOWTERRAIN723 and pointing out another example where a very poor, extremely poor, choice of words was chosen for communication with users. Zendesk wasn’t too bright when they did it.
I have no issue with zendesk or its wording. I do have an issue with bug reports being closed by forum moderators with no explanation, reason given or apology. After we have spent hours or even days in some cases of our own time getting screenshots, writing reports, sending off data etc it’s disrespectful to the users in my view.
“We are closing this bug report as we don’t have the resources at this time to create a fix”. Whilst disappointing, at least something like this is honest and things like that would go a long way to restoring our faith in Asobo right now.
Occasionally Bug Reports have to be merged into duplicate Bug Reports where someone else has reported the same issue. You can see that this has happened in the closed report. If a topic has been closed and merged it is automatically deleted after 7 days in order to keep to forum tidy:
I understand about merging but simply saying “Marked as won’t fix” offers no explanation as to why it isn’t being fixed, no reason given and no apology for the bug having been created in the fist place!
“Marked as won’t fix” is simply not good enough. We give our time and efforts to contribute to these bug reports and all we get is what can be, and is, perceived as “we aren’t going to fix it and we aren’t going to tell you why”.
As I said earlier, “Marked as won’t fix because we can’t identify what caused the bug” or “marked as won’t fix because we don’t have the resources right now”… something like that. At least be HONEST. Don’t just tell us “we aren’t going to fix it”!
I don’t know tthe reason for certain, but logically because it’s an MSFS2020 bug, they aren’t going to bother fixing it because MSFS2024 was imminent and now has come out.
I empathise about the bugs being closed as “Won’t fix” - a few that I cared about on 2020 and wanted to be fixed were marked as “Won’t fix” too.
Just a quick heads up on a technicality: It would be Community Managers closing these, as the moderators can’t see into the bug tracker in order to get the status. But I totally get the sentiment.
I know that that was just an example. I’m going to go off on a little tangent, and this is in no way disagreeing with you. This is just a little rant about the situation and how Microsoft operates.
I would hate for any bug report to be permanently closed because they didn’t have the resources to fix something now. There have been some airport bugs closed with a reasoning of, “Needs new aerial.” So then, they should wait for the aerial and then QA it after the fact. Every bug tracker I’ve ever used has had a status of “Blocked.” They should be using that instead of “Closed.” A really good bug tracker would have a drop-down for “Blocked reason,” with an option that says, “Needs new aerial” so you could query all bugs in that situation.
And last I heard, their bug tracker doesn’t even have geolocation fields in it. (I asked someone six months ago.) So they can’t even say, “Okay, we have new aerials for Italy. Let’s query all the Italy bugs and see if the autogen system has fixed any of these.” Seriously, I just don’t understand why these people operate the way they do.
I would hate for that to be true. That’s another way of saying, “You MSFS [2020] customers are not important to us.” Jörg made that “10 years” statement before MSFS 2024 existed. (At least, I assume it didn’t exist. He said that in 2020. Would be bonkers if they were already planning the next one while launching the first one.) Not to mention, some people opted to stay behind because of bandwidth concerns, and after this 2024 launch debacle, I imagine some people will be on 2020 considerably longer than anticipated.
Some of those closed bugs are also airport and scenery bugs. If both sims share the same world, they are hurting all of us.
I know that was just a hypothetical, but I had to say it.
If that means “this bug doesn’t exist in 2024 because it was fixed in 2024 or made obsolete by larger changes in 2024” then they should say that. That’s what we want to know.
If that means “we want you to file fresh bug reports for the same bugs in 2024”, then they should say that. That’s what we want to know.
Lack of communication leads to fear. Fear leads to anger. Anger leads to suffering. [/yoda]
