This bug report thread has has just been closed. No more visible lines of rain in external view with a simple post by a member of the team: “marked as won’t fix”. And that’s it. No apology, no explanation, no reason given.
A simple comment such as “We removed the lines of rain to save processing power when the sim released on X-box” would be sufficient. Or even “We are sorry but we do not know how to fix this bug we introduced by mistake”…
But simply saying “Won’t fix”. I think it’s quite disrespectful to all of us who contributed their time and effort towards the bug report and gathering evidence.
I am not sure where about this needs to go on the forum to get the attention of the team so I’m putting it in the general area for now.
They said the same thing about a VR bug that they introduced in a Sim Update, ergo “we broke something but now we won’t fix it”.
Not exactly very good is it?! Not sure how they can be proud of their achievements when they fail to properly control bug issues, no matter the priority.
That bug was introduced by a SU too, so it’s hard to understand why it can’t be fixed. It really drives me crazy. I can accept they don’t want to fix it, but I think even a short explanation would have been in order.
As you said, just closing the topic with “won’t fix” is sloppy, sloppy, sloppy.
I put together a list. This may not be comprehensive, but there are over 90 bug reports in this list that have been closed as “Won’t fix.”
There’s a developer stream coming up on November 27. If you’re curious to know why these have been closed, feel free to submit a question asking about a specific bug report (like, ‘Why did the drone roll bug get closed?’), or include a link to this post and ask why so many bugs have been closed as “won’t fix.” (Be respectful in your tone or they might throw out the question.) I’m sure the dev stream will be focused on MSFS 2024, but maybe they’ll entertain a few questions about 2020. And if not, ask about them in the next developer stream after that. If you think about all the people who took the time to log these bug reports and comment on these bugs, only to have them closed, I think we all deserve an answer on this.
Note to the current moderators: Yes, this list is long. I tried enclosing the list in [detail] markdown, but the bug reports only showed up as URLs when I did that.
List is in chronological order from when the bug report was created (oldest first):
Thank you. It’s a lot worse than that. I was a moderator of these forums for three years. I spent a lot of time reproducing other people’s bugs and escalating them to the team to get fixed. In some instances, even finding the root cause of the problem. I didn’t count, but I’d say that about half of this list here is bugs I sent up.
I’m not here to brag about my accomplishments. In fact, I’ve barely logged into the forums in a year. But you can imagine how disillusioned one must feel to see this list. To work so hard to get visibility for other people’s bugs that go unnoticed only to have them thrown in the garbage.
But this isn’t about me. It’s about everyone who logged a bug report in the hopes of making the sim better. What kind of incentive does anyone have to log a bug report around here, if this is what’s going to happen to it?
Well, whenever we close a story with “Won’t fix” in my project(s) it’s not because we don’t wanna do it or don’t know how to do it.
Sometimes the reason is simply that business decided against to do it as it will cost too much time for not enough actual value. Other times it’s about deciding against something specific as a large part of an application is anyway developed from scratch, so fixing something on a specific module which is not entirely broken makes simply no sense.
Usually we also don’t provide additional details about that to “the outside” as it’s about internal communications and the NDA we sign with the employer/project.
I’m wondering if “won’t fix” in this case actually means “won’t fix in FS2020”, because FS2020 will not be getting updates to the core/rendering engine anymore, only content. I guess we’ll find out when the Bug Report forums are updated with the release of FS2024, but a direct clarification would be nice.
@N316TS Thank you for the list, could you add the following one too?
“Won’t fix” usually means a story or ticket is internally closed with no intention to reopen it. As mentioned above one reason can be that larger parts are in general reworked or even created from scratch.
On MSFS24 that affects basically everything related to atmospheric rendering, so they created a new Epic just for this part of the sim with new user stories.
Old stories related to the atmosphere were basically closed as this single item won’t be touched again - however the information out of this item might be anyway part of that new Epic or part of a new story.
For MSFS 2020 however, as the story is closed with this sub status, it means it won’t be touched on the “old” sim.
For something like the drone camera roll bug with its 146 votes, it’s their own camera system. It’s not like they needed to untangle Aces Studio’s spaghetti code or anything.
Home cockpit mode doesn’t disable the virtual panel? They were the ones who wrote the description saying that it does. Then they closed the bug report that said it doesn’t do what they said it did? They didn’t even update the description to at least remove the misleading language. It still says the same (wrong) thing:
The DA62 fuel being incorrect…the DA62 in the sim runs on avgas, but in real life runs on Jet A/A1. I’m not an aircraft developer, but I’m pretty sure that’s a single line on the configuration file that they have to change:
The DA40 TDI bug where the left light illuminates the right seat and vice versa…all they had to do is switch the behavior of the lights. The Baron rudder trim being reversed…how difficult is it to swap an axis around?
Check out the Reno bug. I did the analysis for them. You guys can’t see this because it’s hidden from public view, but I discovered many bugs with the Reno aircraft:
I’ve obviously never been in these aircraft before, so I cannot vouch for these specific aircraft, but typically, this is what I expect to see:
When a landing gear is down and locked, the indication is green.
When it is in transit or otherwise not locked, it is typically red.
When it is up, typically there is typically no indication.
Again, I know that this could be unusual circumstances because every plane is different. But I documented the behavior of every L-39 plane so that a determination could be made by the team as to whether or not these are correct. Below, I have videos from each plane.
What I expected to see:
Plane
Up
Transit
Down
What I saw:
Plane
Up
Transit
Down
American Patriot
American Spirit
Athena
Blue Ice
Drop Bear
Pipsqueak
Robin 1
Sarance
Tumbling Goose
Red Thunder
American Patriot:
American Spirit:
Athena:
Blue Ice:
(Ignore the pink. The pink textures in these screenshots are documented in a separate bug report.)
Drop Bear:
Pipsqueak:
Robin 1:
Sarance:
Tumbling Goose:
Red Thunder:
I spoon-fed them the analysis and they threw out the bug report.
This development team told us time and time again that they were building a sim for simmers, but they’ll put the wrong fuel in one plane and install one of their parts upside-down and then decide not to fix it? If they’re going to build a plane, then for someone out there, it’s going to be their favorite plane, so they’d better support them and do them right.
That’s fine, but I’m guessing you didn’t publicly declare to be supporting said story/project for the next 8 years, just to turn around and blatantly NOT support those projects. I have always defended Asobo and Microsoft when it came to criticisms about MSFS, and I am astounded at what they have already achieved with MSFS2020, not to mention the upcoming MSFS2024. But that does not excuse declaring support for a platform, but in practice blatantly showing such a lack of support by closing so many bug reports.
My bug report around disappearing autogen went unfixed and I see the same glaring bug still there in some 2024 alpha videos I have seen so far (flying around Tokyo). I am kind of glad others are in the same boat, at least it’s ‘not just me’ !
They still support the sim and also are willing to port back some features and aircraft. Some changes however cannot be backported in a sensefull way.
They never actually told that they will or can work on all bugs which are going to be reported over time. “Support” in general in first place means there will be something to guide you of you have actual issues, let it be an FAQ page which stays online and not any guarantee that you’ll get new features or bug fixes on things that are not blocking you from using the software.
If it’s a misconception on my side feel free to point out the line promising all sort of bugfixes on the AGB/your agreement with Microsoft as that’s the only thing which counts, not something interpreted from spoken words.
What I say is check it on the final release and don’t just spread stuff which is likely misinformation based on a crippled version with an entirely different scope as officially communicated multiple times, last time yesterday on the development blog.
Only after reviewing the final build you may claim or report stuff isn’t fixed if you don’t have access to the release candidate or at least the teams backlog. Everything else is just a guessing game and simply not a fact.
Same also goes to the “positive things” about that tech alpha, we simply don’t know.
I understand what you’re saying, and I do realize how Companies work.
What seems inexplicable here is that some of these bugs (such as the slow drone roll one) were simple regressions, bugs introduced by SUs, which were working OK before the SU itself. Or things apparently trivial, such as some of those @N316TS listed.
Maybe they just don’t want to allocate any more resources even to simple FS2020 related things given that FS2024 is about to release, and I’ll live with that. But I’m raging inside that they closed these bug reports without a single word .
.
.