I see numerous bugs in the Bug Reporting Hub that have been confirmed by multiple users yet are still not logged as bugs.
What is the criteria for them to be logged as actual bugs?
Also, are the aircraft specific bugs assigned to their respective designers/teams?
Thoughts & prayers?
if we go by how they treated bugs along these past 4 years:
game breaking bugs in the core sim or in the backend servers tend to be given a reasonable amount of attention, for instance āservers are downā situations usually get fixed within the day
usability bugs in the aircraft models that are a nuance but donāt impede you to fly, such as a switch that doesnt work, are way, waaay down on the priority list, some of them are never fixed
Scroll down to #3
That explains the tags, but it doesnāt explain how/when/why those tags do/donāt get assigned to bugs.
It seems like one of the three CMs (if we have more we never/rarely see them here), to tag the bug.
Based on what they have cursorily shared about their responsibilities here and elsewhere, that seems like a very big ask to get them to read all our bugs and tag them appropriately.
Iāve felt, forever, that there needs to be a dedicated QA person assigned to the management of all these bugs and keeping them tracked and managed.
Apparently, that isnāt a high priority, or even a low priority.
The entirety of the bug-to-developer reporting process here seems highly sporadic and unreliable. I tend to doubt that the developers are even aware of most of our issues. We see this in their responses when someone mentions one in a Q&A and the deer-in-the-headlights looks passes over all three of them. Granted those three are higher-level people in this project, but nonetheless, Iād expect Martial to know what is going on as the producer overseeing the project.
Interesting discussion. We might keep in mind that everything we are seeing is community facing. The various teams involved no doubt have internal systems they use to manage their work. From career experience in corporate America, in a job role only lightly touching on IT, more like end user support amongst other things; IT doesnāt usually provide full visibility into what they are doing. This may be different in the gaming world, but I doubt it. I am actually rather impressed by how much community involvement is solicited; but I would not expect the kind of transparency into proprietary process land in return, just good community relations/communications. YMMV on that score, but the CM effort on this very limited platform to both collect feedback and reflect back any progress is respect worthy.
Theyāre trying to create a virtual twin of the real world, mirroring real-world geography. Theyāre also trying to create a realistic aviation world, using facsimiles of real aircraft, real airports, real weather, and real flight dynamics. Interpretation and understanding of these things are difficult enough for real pilots, especially in the areas they donāt have direct experience, much less the rest of the world.
Itās not a fantasy game with a narrow scope, where they can do whatever and handwaive errors (sometimes making it canon). Itās so vast and so complex that it requires, demands, really, input from subject-matter experts in a lot of fields. And SMEs in aviation really have to be precise - itās part of the culture. Thereās also need for UI creatives and SMEs, and just general noticing of things from everybody, due to all the nooks and crannies a digital twin world creates.
So theyāre kind of asking for it by being in the realm in the first place and the need for community engagement is a natural offshoot. If they ignore that, itās really at their peril. But to be fair, there is a lot of noise.
Totally agree. That said, our input is very likely to be far greater than their output when it comes to agreeing on bugs that are cataloged, etc. They have created a monster IMO along the lines of digital twin for scenery, and aviation career as economy (as opposed to simply a series of linked and engaging flight lessons); so yeah, itās not really lord of the dings out here LOL! All I suggest is that while we keep the good feedback flowing and do our best to document any bugs we are inclined to report (optional for us end users), we keep our own expectations realistic about how much progress the CMs can reflect back and when to expect that. They are downstream of a complex software development effort across corporate entities. There are more than a few different kinds of relationships to be managed and communication can suffer.
100%
Third-party devs have the luxury of doing that in their own time and producing a product that meets their standards. Their reputation depends on it. With the sim being rushed out the door, and their version of things being somewhat generalistic and bowdlerized, most of the issues weāre seeing are self-inflicted and require that feedback.
I donāt know. With all due respect to āEl jefe,ā I remember it taking them more than a year to fix the DX12 ground bug that was well publicized in the community by myself, YouTube videos, literally a thread with 100 examples. Then, in one of the Developer streams, Jefe said, āI donāt think we have enough examples of this; the community needs to speak up.ā To which I was like, āWTF, Jefe!ā
The whole chat exploded, and I quoted it in a forum letter to the developers and Jorg himself. Then, a week later, it got fixed.
So, to me, it feels like things get fixed pronto when Jorg notices a problem. I honestly always get the sense that Seb tends to live more in what he is working on next and screw the past, and Martial is the intelligent guy who loves to build ā ā ā ā but rarely troubleshoots until it explodes on his faceākind of like Dr.Marty in back to the future.
My analogy to you guys is this. If they were building a time machine, I wouldnāt get on it until I saw them all go together and return. On my test run, Iād take Jorg with me as insurance.
Love the analogy. Thereās no doubt that direction is an issue. Totally agree that they arenāt exactly in touch with the community. Itās needed, but again thereās a lot of noise and I thinkā¦ I think thereās a language barrier - not so much English or whatever native tongue, but technical speak.
We donāt always do a good job explaining, those that do get kind of lost in the noise, and I donāt think they do a good job receiving, seeking clarity, and deploying resources. It often feels dismissive, but at the same time not understood.
The voice of reason again. I and Iām sure many others often find themselves agreeing with your thoughts on this. TBH itās not rocket science is it and it only takes a bit of sensible thought to come to these conclusions that we do yet for whatever reason Microsobo are not coordinating it very well at all from my experience.
It just needs a central place where you can easily see if a bug has been logged already. Itās just not very user friendly using the current tools. Itās no wonder the moderators are continually moving stuff around because users repeat stuff and generally are unclear about where to post. The standard report format being repeated in the posts just makes them long and the important information harder to find. A cleaner slicker system with a way to overview whatās already there would really help the community interaction. After all we are the beta test team 
.
Agree. There could be some actual language issues but as you say also itās obvious despite what we are continually told that there are not enough if the right eyes and ears checking this stuff. Even if the initial communication is not quite on point from a user if you have that knowledge and background you know how to steer further communication to get to the bit of Information thatās important. A team with this background dedicated to interfacing with the community and digging out the valuable info on top of the general admin would really help.
Iād gladly offer my volunteer services to help catalog bugs in a cohesive format. Its what I do for a living as a project manager.
I think it would help cut down on a lot of the frustration.
The current walls that exist between serious users who are taking time to report issues and suggest fixes, and the devs and QA testers must come down. I donāt understand all the intricacies of these operations, but is it not possible to have a system where if the feedback you provide meets certain criteria that you are placed in direct contact with the devs and testers if needed to work out the issues and fixes required.
I tried to volunteer and, essentially, got completely blown off and the thread closed and locked.
They donāt want our help and I honestly feel like the ability to report bugs here is to give us the false sense that we have some sort of control over something that we have absolutely zero control over.
Grab you favorite DnD dice and roll āem ā Perhaps a bug will get acknowledged, fixed or nothing at all.
I did that for years here in these forums. I donāt know how many bugs I reproduced and sent up, but it was in the four-figures range. Recently, user AndyXPO started a thread because one of his bug reports got closed as āwonāt fix,ā and that got me searching. I discovered nearly 100 such bug reports that were closed. By a quick sampling, about 50% of these bugs were sent up by me:
Some of those bugs are simple fixes, as far as I can tell, like fixing a line in a .cfg file, so I donāt know why they were closed, but I will tell you that that list had me fuming.
I just did a look around today and there are approximately 1262 open MSFS 2024 bugs in Bug Reporting Hub , of which 50 are marked as feedback-logged and 43 are marked as bug-logged . As a percentage, thatās 7.4% of bugs that have been recorded. Now, having spent a lot of time in that category, I know that a lot of those bug reports are probably user error or add-on-related or duplicates, but even if you cut the denominator in half to make it generous, that would still mean that 85% of the real bugs in Bug Reporting Hub havenāt been recorded.
I donāt know whoās looking at all the bugs. There used to be a few people, and I have stopped paying attention to that, but the team is not big. If you average it out, Bug Reporting Hub has gotten about 90 new bug reports per day since launch. That number will go down over time, and in fact, has already gone down (the first week had about 120-150 bug reports created per day). Itās doable with the right people, but I donāt know the appetite of the team to actually sift through them and follow through with them when the bug report is ambiguous or not detailed enough. There are also tons and tons and tons and tons of MSFS 2020 bug reports that will likely never be looked at in these forums.
And unfortunately, even if they all did get logged, history shows that they might just get closed one day as a āwonāt fix.ā
Iāll raise another point about getting bugs logged; They need to play their own game to see them in the first place.
With MSFS 2020 the very obvious bugs wouldāve been seen by anyone playing the game, but yet the need to create a bug thread and gain hundreds of votes before anything was logged became a necessity. It was and still is such a poor system of prioritising bugs to be fixed.
MSFS 2024 comes along and in the first 10 minutes you can see already a mountain of bugs, you donāt need external community led bug reports, you at your desk at Asobo just need to use your eyes and add those bugs directly into your system.
The fact so many bugs got through on release, the fact they shouldāve known about these prior to release, can only be explained that they donāt play their own game to notice them.
There are 150+ employees at Asobo, are you telling me not one single person went to fly the C152 from cold & dark to notice it doesnāt work at all? Not one employee loaded in VR and saw that the EFB doesnāt work? Etc
I refuse to believe they donāt play their own game, but it appears that they donāt play their own game and this attitude needs to change drastically.
I concur with this. They seem to spend time doing basic tests or setting up a scenario involving a stability test. In their version, that stability test may not do what most simmers would use it for. If the sim maintains stability, it gets a green checkbox and moves on.
They should focus on four basic principles, test the simulator before launch, and reduce the amount of their brief from the community.
Control mapping: This involves ensuring that all hardware behaves in a normal state as it would on a real-life counterpart by conducting a flight test and optimizing click spots on cockpits (does every button work that is simulated?). Does the performance meet heavy load test criteria?
Scenery and world rendering: Does every bespoke airport render correctly? Are there any issues with how it interacts with photogrammetry (think KDFW)? Do the world ground tiles and photogrammetry load correctly? If we offer a photogrammetry feature, it should be ready at launch and not create problems for the end userās visuals.
Weather: Does the weather match the meteorological conditions observed by multiple sources? For example, how many of us have entered an area with visible thunderstorms but nothing in the simulator? A simple test of severe weather would tell us where the testing team can find extreme weather, go into the simulator, and explore the weather. Cross-reference with real-world cameras of the airports where the weather is reported and ensure it is plausible. Turbulence: just because the limited training in a genuine C172 made it feel like the devs were being shaken doesnāt mean that every airplane in the simulator should behave like that. I know hundreds of real-world pilots who consistently tell me that the ārealistic turbulence setting is not accurate.ā Iām one of those pilots who can tell you that having a straight and level flight on some of these planes in the simulator is nearly impossible. So maybe have your internal testing team run this by the countless pilots who want to share their experiences to make this a better simulator.
Testing and Logging: the most significant problem with the bugs logged is that we donāt see the status of anything other than very generic messaging. This proves that no one is paying attention because of two things. If we submit a trouble ticket, the team rarely responds as it would in a usual service desk ticket environment. The other more generalized feedback from the forums, as ābug logged,ā does not show you have any information on ālight at the end of the tunnel,ā for example, a system with an active log that users can search for bugs, with an explanation of when they occur and a workaround, if any? The most critical part is a status message assigned to a team with their expectations of a Fixing date. It would provide helpful information, showing that it has been assigned to a department and that we will see a correction in the future.
Iām sure that some may read this and have different opinions. My views come from two decades in the customer experience environment. The worst thing for customers is to feel that the fix will never come. They can tolerate that a feature doesnāt work, but not having information on who is handling it, and finally when will we see additional patches or releases to the problem is what creates lost customers.
My Personal Comment & Observation
I suspect (I have no evidence of this) that much of the testing is now automated, and release is conditioned solely on the results of that testing. It would explain why many of the visual errors exist - automation has no eyes.