A good developer can do a lot with a crash dump and even more if the crash dump includes a memory dump. Sending those to Asobo will help. While not every crash can be analyzed that way, many, if not most, can (at least if their developers are any good). Basically, what Asobo needs to do is ensure that crash dumps are being sent to Microsoft and bucketized. What that means is that crashes with the same call stack get lumped together so the crashes that are affecting many people are easy to see. Then common crashes get bubbled up in the reporting, get visibility, get investigated, and get fixed without customers needing to explicitly needing to do anything. I say send them to Microsoft because that infrastructure is already in place for Asobo to pull from.
More debugging tools built into developer mode would be great. Asobo isn’t going to give anyone debug bits or real symbols because they want to both protect their IP as well as prevent piracy. I haven’t looked at it that hard, but Flight Simulator seems to have code in it to defeat debuggers. I was getting constant single step exceptions when I tried attaching. It would be great to have symbols and debug bits for sure, but I don’t see it happening.
IMO, the biggest problem with reporting bugs in general to Asobo (and it is the same problem that dedicated internal testers would have) is that it is difficult to provide repro steps for many bugs because they happen in the middle of a flight. Isolating bugs in this environment in order to provide a useful bug report with sufficient steps to reproduce is simply going to be too time consuming for most of the small set of people that might otherwise have the skills to do it. Honestly, I’m not filing that many bugs because I can’t provide enough useful information at the time and I’m not really willing to spend my free time investigating to the point where I can isolate said bug. And I’m certainly not willing to do this for free, no matter how I much might love Microsoft Flight Simulator. I would be willing to take a preview build and give ship/no ship feedback–provided that Asobo made any such builds painless to download and easy as well as quick to roll back if need be. Basically, I’d want a dedicated high-bandwidth port so that if I needed to wipe my whole Flight Simulator install, it wouldn’t take me half a day to get it back.
It would probably be much easier on everybody if Asobo could design a “flight data recorder” that would keep track of plane state. Maybe it could only be in a rolling buffer, but if you could hit a button when you encountered an issue and the resulting file would allow the plane to be put back in a state around when the bug happened, then it would provide a means for we as a community to be far more helpful. I could certainly see encountering a bug, pushing a button and being able to enter a quick description of what was going on and then having the report along with the data being automatically sent off to Asobo.
Additionally, it would provide the basis for automatic resumption of a flight after crashing. I’ve only crashed once, but it was on approach after a two and a half hour flight and it was very frustrating. While I was able to use “travel to” to get back (and I was pleasantly surprised that it worked reasonably), it didn’t put me exactly back where I was and I wasted a few minutes getting back to the pre-crash point. If I were in cruise, the coarseness of the feature would have made this nearly impossible (assuming I crashed in the middle somewhere). At least that is my assumption. I’ve tried setting the dashed line to arbitrary spots on the flight diagram, but it hasn’t worked. And even if it were possible, there is no way of knowing exactly where the crash happened in the profile. Slew mode is an obvious possibility, but again, how do you know where you were when you crashed? And with flights not logging in developer mode, it is highly likely that I would forget to turn it back off after slewing and end up with my flight not being logged. As an aside, they need to prompt for flight logging at the World Screen if you are in developer mode when planning a flight and also if you turn on developer mode mid flight.
My other comment is that Asobo needs developers flying the simulator on a regular basis. Like “Dev Fly Fridays.” Maybe every Friday, developers fly the simulator. Aircraft (and maybe even parts of the world) are assigned out to individual developers on a rotating basis. IMO, that is the only way Asobo is going to get a handle on the state of the simulator. Developers need to be actually trying to do normal stuff and encountering the same issues that we as customers are (and experiencing the same level of frustration). I’d also encourage the use of second and third machines to be constantly in use for temporally long flights on autopilot. This would help flush out many of the autopilot issues we’ve been seeing, as well as random stuff like engine shut downs, etc.
Granted, I’m making an assumption that Asobo developers aren’t currently flying regularly in the simulator, but given the types of bugs we are hitting, it seems hard to believe that they are. Or maybe other forces are in play…In any case, they should either start doing this or possibly consider ways to make it more effective if they are already spending time inside the sim.