

ACTIVE SKY XP PLANE REALLY BOUNCY CODE
For example, the FF A320 crashing inside CEF on a worker thread is registered as an X-Plane crash (and we see it in our auto-reporting view) but it’s not our code and there’s nothing we can do about it. There are a bunch of cases where plugins do not get correctly tagged – in particular, we regularly see crashes on random worker threads spawned by plugins since we don’t know whose thread it is, we can’t blame the plugin. A crash is a plugin crash (and you see the “we crashed because of a plugin: XSquawkBox” or whatever) if the sim crashed while executing code on behalf of a plugin or inside the plugin on the main thread. We categorize crashes into plugin and non-plugin crashes starting with 11.32 we actually get a statistical picture of this.


This is a deployment problem that really needs to be solved, but it’s orthogonal to true app crashes.) (There is an in-between area where an add-on is mis-installed because it has a library dependency that the user hasn’t met. That is, they are caused by an add-on that should not have shipped. While I would like to make this code less hostile to users, it’s also worth noting that these cases are ones where the author of the scenery pack would have been able to fix this if they had loaded their own work even just once. This failure mode is user hostile in that you can’t fly, but it’s not a crash – the refusal to load is the code working according to design. ter file, the sim will refuse to proceed and quit. For example, if you load a DSF with a missing. The sim quitting on purpose because of bad content is not considered a crash. This number has been remarkably stable – it’s not a ton different between 11.26, 11.30, 11.31 or the 11.32 beta. X-Plane’s overall crash rate (all causes is approximately 14% – which is to say, for all of our users using analytics, for every 100 times they launch X-Plane, the sim quits in a way we did not expect or want 14 times. The more gathered data we get about crashes, the better shot we have at addressing the issues. The rest of this post gets into the weeds if you tune out (and I won’t fault you if you do) the TL DR is: please turn on our anonymous analytics, and click “send” if you get the crash report form. We have learned some things about X-Plane’s performance and stability though.
ACTIVE SKY XP PLANE REALLY BOUNCY SERIES
We really haven’t found a series of smoking guns we could fix to improve stability. Over the last few weeks we have spent a tremendous amount of developer time investigating reports of instability, crashes and performance problems, and the results have been quite unsatisfying. Our own server should serve the latest weather we have, whatever that is. NOAA weather was plagued by 404s when the server posted METARs didn’t meet the date/time scheme X-Plane expected. The big item for RC2 is that X-Plane now uses our own replicating METAR servers. If you think RC2 changed your framerate from RC1 (for better or worse), it is imaginary. We’ve posted X-Plane 11.32 release candidate two – it contains very few changes from release candidate one.
