X-plane 10.31 is now final; if you’ve run X-Plane 10.30 you probably already know that. 🙂
Steam Users: the Steam Edition of 10.31 for OS X was broken, so we rolled it back to 10.30. We’ll get 10.31 out on Steam as soon as we can fix the problem – it should be a few days at worst.
Since X-Plane 10.30 shipped, we have received a lot of feedback about the stability of X-Plane 10.30 – or rather, the lack thereof. We are getting more bug reports that the sim crashes, more tech support requests, and more discussion of crashing in the forums.
We don’t have a good way to characterize with hard data how much less stable 10.30 may be – unfortunately even the crash reports we gather don’t give us a statistically clear picture.* But with this much user reporting, stability is our first line of inquiry. 10.31 will come out shortly (and will fix a few issues) and we’ll keep investigating problems and pushing small patches (to fix stability issues without introducing new ones) until we’re back on solid ground. The rest of this post discusses some of what I’ve seen so far looking into stability issues.
Since X-Plane 10.10, we’ve had the ability to send crash reports** directly to Laminar Research. Here are a few suggestions:
Reproduction steps are gold to us – sometimes we’ll see a crash and the proximate cause is “hrm – the sim crashed drawing an OBJ”. Sadly this doesn’t tell us much about how to reproduce the crash – and clearly the sim does not crash every time you draw an OBJ; it wouldn’t start up.
Our crash reporter can only trace the origins of a crash through X-Plane code.*** Unfortunately, of the top 5 Windows 64-bit crashes in 10.30r2 (and this represents most of the crashing going on), 87% of the crashes originated in an OpenGL driver from AMD, NVidia or Intel. (This does not mean the driver is bad – it could mean that X-Plane sent the driver junk data. Or it could be the driver’s fault. We don’t know.)
Unfortunately that means that for the vast majority of 64-bit crashes, we have no idea what the sim was doing when it crashed – the trace from the driver will contain junk. All we know is that we were, in fact, in the driver at the time of death. (We also have the log.txt but often it just indicates the user was flying.)
This is a long term problem that we need to address as developers with our crash report technology; we have some ideas on how to fix it but they will take time to implement. Clearly we’ve hit a point where the low hanging fruit (crashes that affect a lot of users but are entirely in X-Plane code) are gone.
We do not have good statistics (yet) for what percentage of submitted crashes were on X-Plane installations heavily augmented with add-ons, but it is not uncommon to see a user with a custom aircraft running a custom plugin, an online flight plugin, tons of custom scenery packs, and general utility plugins.
This kind of customization is great! We wouldn’t have added the SDKs if we didn’t want people to use them. But when it comes to isolating a crash it does make things quite a bit more difficult.
My goal for X-Plane is to not have X-Plane crash due to bad third party add-on data, no matter how badly it is formed. To that end, when I find cases where bad data will crash the sim, I am adding code to protect, document, and shut down based on the error. (Some errors are recoverable, some are not, but the important thing is to give the author some feedback as to what is going on.)
In the long term I think we need to add better diagnostics to our crash reporting to show what add-ons are involved in a crash. If you have 1000 scenery packs, I can’t go download them all in an attempt to reproduce a crash.
In the short term, if you are seeing instability and you have third party add-ons installed:
Reproduction steps are gold to us! The combination of the add-on and simple steps to reproduce let us find and fix problems, even with third party add-ons. If you have a flight that crashes, please try to simplify it. Try going directly to the location that you were at where you crashed, starting with the engines on, etc.
While we’re talking about stability, I have to mention Yosemite: on OS X the vast majority of bug reports we’re getting that involve “weird stuff” and crashes involve Yosemite. We’re still trying to sort out the issues, but Yosemite is definitely the most disruptive OS X major version release we’ve had in a long time, and because it’s free, a lot of people downloaded it.
A major OS upgrade is when the OS vendor can make major changes, drop old technology, etc. On OS X it also means new OpenGL drivers (because the drivers are always packed with the OS), so it’s a potentially disruptive update.
Update: it turns out Yosemite also broke our automatic crash reporter, which would explain why none of the common Yosemite crashes show up in our top crash list. 🙁 Some users have sent me the Apple crash reports that appear (since our crash reporting doesn’t run) so that we can diagnose what’s going on.
10.31 should be out in a day or so (including Steam); as we continue to find and fix stability problems we’ll continue to issue small patches. We’re looking to do a 10.35-type release with small features and new airports; the current plan is that Julian and Tyler will do a public beta of the new airports (as a single separate scenery pack) so that people can try the new airports and spot problems before we get into beta.
* Crash reports don’t tell us how many times the sim was run overall; users with stable systems don’t send us any data, so an increasing crash report incidence would be meaningless – we don’t have data about increasing or decreasing use of the sim.
** Here we’re talking about true program crashes – the uncontrolled exit of the sim for unknown reasons. If you have a controlled failure, e.g. you load scenery and it’s missing objects and the sim refuses to run, you don’t get a chance to auto-report that. We also don’t view this as a stability issue – X-Plane can be very unforgiving about broken third party content, and we can have a separate argument about whether this is a necessary evil or terrible user experience (or both!), but there’s no diagnostic information to gather.
Update 2: Blog comments are now working again.
*** The problem is that for 64-bit there is no standard for back-tracing a stack without the debug symbols to decode the stack linkage; there is no standard link register. I’m guessing that the ABI designers thought they were helping the compiler guys optimize, but in practice it makes debugging other people’s DLLs miserable. Microsoft publishes debug symbols for every DLL they make ,which is a big help, but the driver writers do not.
Quick note: 10.31r2 is up on servers now. Please try it!! We think this is a keeper 10.31 – it has just a few more bug fixes. A list of fixes is here.
If you develop 3-d models for X-Plane using Blender 2.49 on OS X, do not upgrade to OS X 10.10 (Yosemite). Something changed in the OS that causes the python scripts to not load, which means you won’t be able to export.
(As a side note, I am of the opinion that if you use your computer for work, you should not install major OS upgrades without investigating first. If Apple is going to break support for something intentionally, it will be in a major version. Once you install the new OS, going back is hard. So why jump in so fast? These days I don’t believe that any one OS update is so much better than what was there before that it trumps keeping your productivity software working. But then, as Chris points out, I am older than dirt.)
Update: Chris found a way to make Blender 2.49 work with Yosemite. For reasons unclear to us, the Python 2.5 framework that comes with the OS in Yosemite is just a symlink to version 2.6 (rather than the real Python 2.5). If you delete the symlink and put in place the old 2.5 binary from an older OS, Blender starts working again. I’ll post instructions when we have something written up in readable form, but this is a tricky mod at best – you have to change admin-writeable files in your library.
Update #2: Hi guys, Chris here. Here’s an outline of the steps that you’ll need to take…and you’ll need to be an administrator of course since you’ll be running sudo. A basic disclaimer….you should have a full bootable and recent backup of your system anytime you mess with system files (even though this should be relatively straight forward). These instructions worked for us but you should follow them at your own risk.
/System/Library/Frameworks/Python.framework/Versions/2.5
cd /System/Library/Frameworks/Python.framework/Versions/
ls -al
to get a full directory listing. If you see 2.5 -> 2.6, you have a symlink from 2.5 to 2.6 which is what’s causing Blender to use the wrong Python version. IF YOU DON’T SEE THIS, YOU DON’T HAVE A PROBLEM!
sudo rm -rf 2.5
sudo cp -R some/path/to/the/good/2.5 .
sudo chown -R root 2.5 sudo chgrp -R wheel 2.5
X-Plane 10.31 release candidate one is now live. To get it, you need to run the X-Plane installer and check “Check for new betas as well as updates” – 10.31 isn’t final so it won’t auto-notify you.
Please do get 10.31 Release Candidate 1 and try it. We’d like to go final with it shortly.
The release notes are here – that’s basically a list of the bugs fixed. Go read them if you want to know what is fixed! (If the release notes don’t say it is fixed, then there is no change from 10.30.)
Report bugs here.
Please do not report bugs in the comment section – a little bit of me dies inside every time you do.
It looks like we have some bug fixes that will go into a 10.32, but for 10.31 I wanted to get out smaller fixes that we could ship quickly. So hopefully 10.31r1 will be the only 10.31 patch and then we can get fixes in for 10.32 in another week or two.
Just a quick note: last night I fixed the bug in 1030 where the sky is corrupt when you use the instructor’s station and HDR together. This is the last of the ‘quick’ fixes for 1031, so I’m hoping to have 1031 cut over the weekend.
When I first saw pics of this bug I thought it might have been an old driver, but the number of users seeing it made it clear that it was a real thing; as it turns out, it was a subtle OpenGL screw-up by me. Frankly the amazing thing is that we’re not seeing it on every Windows driver. (From what I can tell, the AMD drivers “helpfully” work around my error, hiding the bug.)
We’ll post release notes with the beta with a complete bug fix list.
For about a year there has been a subtle bug in how X-Plane draws taxiways: if you build an S-curve shape out of a single bezier and it is almost perfectly symmetrical, X-Plane would go “nah, why bother” and replace it with a single straight line segment.*
So in 10.30 I fixed it, and the result was a bunch of broken airports with missing pavement. (YMML is high on this list!)
It turns out that these airports have authoring errors – typically a segment of pavement that should be straight instead being formed by two overlapping beziers. This is definitely wrong, but due to the bug, X-Plane would simplify the overlapping S curve into a single straight segment and the layout would work. Only now that X-Plane correctly renders the S curve does the taxiway fail (because taxiways may not have overlaps). So two wrongs may not make a right, but they do make a “hey, that looks okay, let’s ship it”.
Note that the overlaps depend on the rendering setting of X-Plane – a different S curve is formed at different rendering settings; the overlap that causes the taxiway to disappear may only appear at a particular rendering setting.
For 10.31 I am going to undo my bug fix. This doesn’t make me happy, but I think it is necessary:
This is too much uncertainty to solve ‘by hand’. So my plan is:
This isn’t going to be a quick process, but then it can’t be, because third parties have apt.dats shipping now that only work when X-Plane has the buggy taxiway code in place. So we need to ship WED and then give third parties enough time to go back and check their layouts and fix them if necessary.
I expect to get a 10.31 beta with the taxiway code changed back this week.
For WED validation, I have some test code to detect errors but it isn’t ready yet. The problem is that it’s not good enough to detect errors with overlapping beziers**; we have to consider two bezier curves near enough to each other that with the error in rendering introduced by WED’s rendering settings, we get an overlap. (So authors, better be safe than sorry in creating your pavement.)
If there’s a moral to this story, I think it’s this: when we (LR) don’t provide good tools for authors to validate that their work is correct, the resulting body of work will end up with subtle errors.
* X-Plane renders beziers by measuring how far the mid-point of the curve is from the average of the ends. As long as this distance is ‘too far’ and the iteration count isn’t too high, X-Plane divides the bezier in half and repeats the process. In this way beziers are broken into enough line segments to approximate the bezier within a minimum error limit. The rendering settings control the error limit.
The bug: if the curve was a ‘balanced’ S curve the mid point of the curve was the average of the end points and X-Plane went “great, no error” and stopped dividing.
** Which is already not an easy problem – the analytical solution for bezier intersection is a 9th order polynomial!
Users with newer Ubuntu versions have reported they can’t get X-Plane to start after the update to 10.30, while it worked fine with 10.25.
Since 10.30, X-Plane links to libudev to discover devices like the Oculus Rift on Linux, and that has caused a few hiccups with some of your Linux installations out there.
No, this post is NOT about the Oculus Rift on Linux!! If you want to know the current state of Oculus Rift development, go and read this one. Though there’s a little update: At OC1, Oculus confirmed they still want to support Linux. They didn’t say when, though.
Back to libudev. X-Plane for Linux is built on a very old Linux distro, Ubuntu 10.04LTS server, which is horrendously outdated by now. But it has the advantage that binaries built on that an old version, will work with basically ANY distro out there today. Basically, the older the distro is we choose for building, the more distros users can run the binary on.
The problem with libudev0 though is, it is so old, that modern distros just don’t ship it anymore! You can only get the newer libudev1. As a work-around, you can simply sym-link libudev.so.0 to libudev.so.1 to make X-Plane find the newer version.
Starting with X-Plane 10.31, we will remove the load-time dependency on libudev again so everything is back to working like it was on 10.25.
In the future, we will load libudev dynamically based on the version the Oculus SDK requires (This is when an Oculus runtime is available for Linux, which currently isn’t).
Summary:
As for the sym-link work-around, avid Linux user and plugin developer Bill “Sparker” has created a thread on X-Plane.org where the appropriate paths for the symlinks are posted for a variety of different Linux distros.
UPDATE: The method described here works just as well and has the benefit of limiting the change to one application only.
As many of you are aware, we have been showing custom versions of X-Plane with support for the Oculus Rift at different shows and conferences. Naturally you want to get your hands on it as quickly as possible, and some of you have engaged in lively discussions on the forums and in the Steam community, which is why I’d like to give you a quick update on the current state of development.
First of all a big “thank you” to Bob from RC Simulations, who provided us with a DK2. His order was in the first batch, and he generously lent it to us until ours got delivered a few days ago.
The good news is that my DK2 now sort-of works with X-Plane on my Mac and PC. Now hold your breath, because the “sort-of” is an important part of the story. The bad news is that Oculus recently introduced some fundamental changes into the way the display of the Rift is exposed to the operating system. The changes were quite disruptive and haven’t even made it to Mac and Linux yet.
The latest SDK from Oculus comes with a proprietary display driver for Windows, to allow for a smoother display with less motion blur because it runs at 75Hz (instead of the 60Hz of virtually every computer monitor nowadays). This driver apparently works okay for Direct-X based games, but doesn’t work at all with openGL applications like X-Plane. For Mac and Linux, not even an unstable driver is available as of now.
On Windows, if we try to use the low-latency “Direct-to-Rift” mode, we get a Blue Screen of Death. It is a well-known problem of the latest Oculus SDK, that it doesn’t work with openGL. Any title with native DK2 support you find out there runs on DirectX, which also means it is a Windows-only title.
A user on the org forum posted this Star Trek quote:
“The needs of the many outweigh the needs of the few” (or “the one”).
suggesting we should’t wait for Oculus to provide Mac and Linux support and instead release a Windows beta RIGHT NOW.
In case it’s not entirely clear from I wrote above, the platform availability is not the problem! Even if we were to release Windows-only, we’d still need working openGL support in the Oculus display driver.
Using the DK2 in “Extended Desktop” mode like the DK1 is not really an option. Due to the DK2 running at 75Hz, and your primary monitor at 60Hz (unless you still have one of those heavy CRT monitors) you will get terrible vsync. It is dropping frames left and right (regardless of your actual frame rate!) causing what people on the Oculus forums refer to as “DK2 judder”. In fact, DK1 looks better than DK2 right now, given we can only use the “Extended” mode, and that is just lame.
I am heading out to Oculus Connect later this week, where I hope to get some insight into the what and when of openGL support, the roadmap for their drivers and if we are ever going to see native DK2 support on Mac and Linux.
As of now, I have to tell you that for anything but DirectX-based games, the Oculus SDK is so beta that it is not even alpha. We will have to wait for future versions of the Oculus SDK to fix those issues.
X-Plane 10.30 Lives!
Laminar Research, creators of the X-Plane flight simulator franchise, has released the latest update to X-Plane, version 10.30.
This latest release represents the largest and most significant X-Plane update to date. It not only contains numerous fixes and performance improvements, but also some substantial additions to the product itself. Foremost is the inclusion of the new GPS. The previous versions of X-Plane also included a GPS instrument but it could only do direct-to navigation and could not implement a GPS approach. With the recent introduction of GPS enabled approach systems at many airports, the new GPS in X-Plane will allow customers to practice actual GPS approaches using an instrument familiar to most general aviation pilots. The new GPS is a drop-in replacement for the old X-Plane GPS, so that with one click in Laminar’s PlaneMaker, old aircraft can be upgraded to the more IFR capable version. The X-Plane 10.30 default aircraft come with the new GPS already installed. The new GPS is based on the Garmin 430 and Garmin 530 and both variants are included.
The 10.30 update also includes major improvements to both the weather and scenery systems. The system for the placement of autogen scenery has been refined so buildings, trees, and other objects more accurately reflect their real-world counterparts.
With the recent release of World Editor 1.3 and the Airport Scenery Gateway, hundreds of new highly detailed airports have also been included in this latest and major update to X-Plane 10.
We’ll have a 10.31 bug fix patch, probably in about a week, with a few straggler bugs that didn’t make the cut. In the meantime, aircraft designers can start using the new GPS.
