You might have noticed we’ve been working our tails off to make X-Plane 11 an amazing sim, with tons of new features, and during that time we didn’t have the resources to do anything further with our proposal to publish X-Plane usage data. The good news about our delay is: we now have usage data for both X-Plane 10 and X-Plane 11.
Since one of us (ahem) remembered we had promised to provide this at intervals, here’s the latest data update. It’s still not particularly pretty, but we have a handful of easy-to-digest charts, plus the raw data at the bottom of the post for those that are interested.
Items of note
All data in these charts are for users of the full version only—we’ve filtered out demo users.
If an aircraft’s name, studio, or number of engine fields in Plane Maker are changed at any point, the aircraft will show up in the data as two different entries.
Aircraft
Hardware
Raw Data
There are four files here: hardware data and aircraft data, for X-Plane 10 & 11. Each contains all the information we have since September 2015, for paying customers only (no demo users).
[This post was co-authored with Tyler Young of Laminar Research to provide more insight into the design process for X-Plane 11, and cross-posted on the Blind Pig blog.]
A few years ago, we ran a survey of X-Plane users. One of the questions was: If you could improve one area of X-Plane, what would it be?
The most common response was, overwhelmingly… the flight model (cue rimshot). Yeah, right. Of course the number one response was the user interface. We took that criticism seriously, but we didn’t want to incrementally improve the user interface and the experience of using X-Plane when improvements were needed throughout the entire application.
So instead, we decided to redesign the user interface from the ground up. Now, two and a half years later, we can finally talk about it!
Back to Basics
Unless a strong brand is already established, I like to start with typography on most projects like this. Font weights, text colour, letter spacing and line height are carefully considered for each typeface option. And the results are always viewed on screen since that is where users will be experiencing the product. Often when going through this exercise, I frequently find a font family I think will work for the interface, only to discover its legibility is less than ideal. We explored several font families and decided on Roboto. It offered a comfortable reading experience for UI elements and the ability to easily extend the brand online. An updated colour palette was also developed for X-Plane 11. I tend towards monochromatic colour schemes with gradations of each colour filling out the palette. I started with the blue value from previous versions of X-Plane but created a darker overall scheme to use.
All of this was collected into a Component Library. This made extending the interface fast and easy and provided a consistent point of reference for UI elements.
A sample of the X-Plane 11 Component library
Let’s Get Visual
For X-Plane 11, we wanted to make everything as visual as possible—long, condensed lists of aircraft, airports and settings were dropped in favour of tiles, maps and ‘wizard-type’ user flows. Previously, if you wanted to pick where you were going to start at an airport, you had to navigate through a long text list of runways and ramps; now you can use the visual location picker and just click on the map.
For weather, there’s no more text descriptions of cloud and wind layer heights; just click and drag! You also get visual indicators of precipitation, and real weather gives you a preview that looks exactly the same.
Under the settings screens, joystick configuration has been vastly improved. We’ve worked hard to provide a comprehensive list of interactive images of your hardware, so you don’t just have a text list of buttons that don’t mean anything.
Filters, Search and Settings
In some cases, there’s no avoiding text lists. X-Plane is a very comprehensive and powerful flight simulator, and as such, there’s an incredible amount of configuration that needs to take place before taking flight. For version 11, all text-based selections support filters and/or search. Gone are the folder views and unmanageably long text lists; instead, users can now filter along all sorts of dimensions.
Ready for Takeoff
Overall, I was extremely happy with the re-design process—I really enjoyed working with the team at Laminar Research and we feel we really improved the user experience on X-Plane 11. But what matters most is what you think. So far, initial reviews are positive—if you’ve tried it out, please let us know your thoughts.
This morning I found out why certain plugins (e.g. SeaTraffic, etc.) are crashing X-Plane 10.50 beta 1 on startup. Beta 2 was being uploaded when I found this, but I’m going to fix this bug first and recut the beta, as it’s a big bug (since it renders many users’ systems to be dead-on-boot). Beta 2 should be up by tomorrow morning but might go live some time today if things go well.
The plugin-crash bug is a regression bug – X-Plane used to do something right and has now “regressed” and is doing it wrong in X-Plane 10.50 beta 1. This is our bug to fix, and we will fix it in beta 2; no plugin will need any changes, and the plugins crashing in beta 1 will start working again in beta 2.
That’s everything you need to know about the plugin crash bug. What follows is a very long and verbose write-up of the crash (think of it like an NTSB accident report). Perhaps it will provide plugin authors with some insight into where compatibility problems come from, and why early betas can be unstable.
A Proximate Cause: Loading an OBJ “Too Early”
We’ll work backward from the proximate cause (e.g. literally why did the plugin crash) and work our way backward to eventually understand the “why” of this crash. The fix for the bug is relatively simple, but you can’t know if a bug fix is correct without understanding the complete why; bugs like this take a lot more time to diagnose than to cure.
The crashing plugins are all calling XPLMLoadObject from their XPluginStart callback – that is, they are asking X-Plane to load an OBJ at the earliest possible time they can. This is totally legal! But it turns out that:
X-Plane isn’t ready to load an object at plugin start and
The penalty for doing so is a lot worse (a crash always) in 10.50 than in 10.45 (a crash rarely).
Why isn’t X-Plane ready to load objects? The answer lies in a little-known part of the OBJ file format called “conditionals.” Conditionals are a lot like C preprocessor macros – they are IF-THEN statements in an OBJ that let you make parts of your OBJ file only run in certain settings. For example, we use conditionals to remove the artist-drawn shadows from the static aircraft when X-Plane is in a mode that can draw shadows dynamically; this prevents “double-shadow”.
Conditionals are weird – they work not by evaluating the condition when we draw, but rather when we load; if a conditional is false in the OBJ, that text in the file is literally not used.* This means we need conditionals to work at load time, which in our case means when XPluginStart is called.
Unfortunately, conditionals are set up when we load preferences, and we load preferences after we call XPluginStart. So when these plugins load an object, the conditional system isn’t inited, and the OBJ loader crashes. Since we called the OBJ loader from a plugin, the plugin gets blamed. (A plugin author looking at the plugin crash can easily tell what happened – “I called XPLMLoadObject and it exploded!”.**)
Is this typical? Yes. Often it’s the combination of special rules for initialization, plugins using code in a way the sim doesn’t, and multiple subsystems that cause crashes.
Why Now?
When I found the code path that was causing the crash, my first reaction was “this is a mess…how did this work in X-Plane 10.45???”. So I went back to the X-Plane 10.45 code and found that this was broken in X-Plane 10.45 too! So what changed?
The answer is that in X-Plane 10.45, the conditional system would only crash (due to not being inited) if it was used; in other words, any object with IF SCENERY_SHADOWS (for example) would crash if loaded from a plugin at XPluginStart. But if you didn’t use the conditionals, things worked fine. And my guess is that very few plugin authors use conditionals in their objects.
What changed is that X-Plane 10.50 uses the conditional system for every object load, even if you don’t have an IF statement. So now the crash is 100% reproducible, not a rare “five things must all go wrong at once” kind of crash.
Is this typical? Yes. This is a bug where something was fundamentally broken for a long time, and an incremental internal change in how our code works changed the symptoms from ‘rare’ to ‘always’. This is very typical of beta bugs.
There may be other bugs like this too – it looks to me like objects loaded from XPluginStart with named lights might not get their named lights.
Why Do You Need Conditionals If I Don’t?
The next question this raises is: why did you monkeys change the OBJ loader code? What was wrong with what we had before? What kinds of X-Plane features cause this code change that break plugins?
The conditional code changed to fix a bug that shipped in X-Plane 10.45. The bug is: if you start the sim with HDR off and then turn HDR on, some spill lights don’t appear. The cause is that the OBJs are loaded with spill lights stripped out for performance*** (since HDR is off). In X-Plane 10.45 when you turn on HDR, we reload a lot of objects – but not necessarily the ones we need to, and the spill lights are lost. Rebooting brings the lights back.
To fix this, I modified the OBJ engine to track which conditionals any given object uses. If you add “DEBUG” to the end of your object to view the diagnostics, you’ll now see this in the output. When you change a rendering setting in X-Plane 10.50, only the objects that use a conditional that was affected by the settings change are reloaded.
That’s a big improvement in loading rules compared to X-Plane 1045. Turn on HDR and only objects with spills are reloaded; turn on shadows and only objects with optionally baked shadows are reloaded. But it means we need to use the conditional system on every object load to set up those flags; that’s what exposed the bug.
Is this typical? Yes! What we have is a simple refactor making different use of an internal API to fix a bug, and the results make a separate existing bug worse; that separate bug is reproducible only via plugins.
Is There an Ultimate Cause To All of This?
When fixing bugs like this I have to ask myself “is there a way this could have been avoided?”
The root of this bug is the root of a large number of plugin quirks and edge cases: XPluginStart (the first thing a plugin does) is called insanely early in X-Plane’s load process; as a result, a lot of the SDK isn’t actually available.
The decision to call XPluginStart early is a bad decision, and it is one that I made, well over a decade ago, to solve one specific problem. At the time, X-Plane (6!) had no option to save the selected AI aircraft to preferences. XSquawkBox needed specific AI aircraft loaded to support multiplayer, and it was really slow to let X-Plane load 20 random aircraft, then reload them all later.
To “solve” this (and I use the term loosely, since this one fix has been the source of so many bugs) I put XPluginStart before almost all parts of sim load, so that the XPLMAircraft API could let a plugin pick the AI aircraft before they were loaded, influencing the first load.
If I had a time machine, I’d go back to 2000 and kick myself in the ass. This early in load, virtually all rules of how X-Plane work are wrong since so much of the sim is not yet loaded. Plugin authors already cope with this by “deferring” their work until the sim has fully loaded; our advice for a while has been to not touch any aircraft before this point.
So is this typical? Yes – it’s yet another edge case introduced by plugins starting unnecessarily early.
* If you are wondering why conditionals work at load time and not run time, the answer is instancing. X-Plane does the complex analysis to categorize an object as instancing-friendly when it is loaded; attributes disable instancing. The conditionals run at load time so that if attributes like ATTR_poly_os are removed for shadowing, are removed by conditionals, then the object becomes instancing-friendly (because the conditional is like removing the text).
In other words, by having conditionals “pre-process” the OBJ file, you don’t pay for what you don’t use.
** If you call a plugin API from your plugin and the plugin code crashes, it could be X-Planes fault or your fault; plugin APIs may crash if given bad arguments (e.g. a junk pointer for a string argument).
*** This is the same idea as above; by removing stuff you don’t use like a spill light that isn’t seen with HDR off, we can get X-Plane onto a faster path. For example, if an object contains a spill light with a dataref, it can’t be instanced; if the spill light will never be drawn, deleting it makes the object instancing-eligible.
Please try X-Plane 10.41 release candidate two by running our installer, updating, and checking “get betas”. More notes here. Release candidate two gets in the datarefs that I (stupidly) forgot in RC1.
Despite many of the Lufthansa Pilots being on strike, Ben made it to Paderborn for the 13th FlightSim Conference in Germany. The event was held at the Paderborn airport, where the airport fire brigade pulled out two of their fire engines to the tarmac – the freed up hangar space was then used as the exhibition floor.
The FS Konferenz starts with a developer’s dinner, were FSX and X-Plane developers drink beer together talk about the development experience, then has a day of public exhibition, talks and interaction with users and ends in the traditional “captain’s dinner”.
We are extremely satisfied with this year’s conference. Not only were there more exhibitors and more visitors than last time, but also the impact of X-Plane is growing steadily. This became evident not so much in the public exhibition space, but in the little ad-hoc sessions we had with other developers. FSX developers who would not have touched X-Plane with a ten foot pole a few years ago were now asking us questions: How do I make a great landclass scenery? How do I make my add-on work with the X-Plane weather engine? How can I make 3d grass next to the taxiway in a way performance doesn’t suck? How do I program a gauge for X-Plane?
I think we are in for a round of new add-ons that will finally come to X-Plane.
X-Plane 10.35 is now officially released! If you run X-Plane, it will prompt you to update. Lots of details here!
I’m still trying to get WED 1.4 to public beta – that’s high priority right now!
X-Plane 10.40 is currently in development. Austin has some new features that he’s letting people test-drive; I’ll post more about 10.40 in a few weeks.
Note: Oops – I wrote this a week ago and forgot to post it. 10.35 will probably “go final” shortly.
If you haven’t tried X-Plane 10.35, please do. Check “get betas” in the updater to get it. Just one bug fix and a license file in the release candidate. A Steam RC should come soon.
Chris took a sledgehammer to the Windows build materials for the scenery tools and pretty much rebuilt everything for Windows; I’ll have betas in a day or two.
UPDATE: The RC is available on Steam also. To get it, right-click on X-Plane in the Steam library, click the “BETA” tab, and then select the beta to opt-in to.
The X-Plane scenery tools are open source; their bug database is open too, so that anyone working on the project can see the status of all bugs.
We recently merged the scenery tools bug base into the gateway bug base; in the process I audited about 70 open WED bugs, and finally closed all of the bugs where the original filer did not provide adequate materials to reproduce the bug. Typically these bugs had been sitting, waiting for user feedback for at least a year.
I’m looking at the feature request list next; it is also about 70 items long and needs some auditing. The old bug base had about a million “levels” of bug status, so it was easy to leave a bug in some partial state and ignore it forever. The new bug base does not, so I think I need to either set the feature request as something we want or kill it.
One problem: a lot of the WED feature requests aren’t feature requests at all; they are requests for changes in the underlying scenery system. E.g. if you say:
Allow WED to edit the height of the underlying terrain of the global scenery.
The only possible response is “unable”; WED cannot do this because the DSF file format cannot include this information; if you had some way to edit such data in WED, there would be no place to save it in the scenery pack that is built.
Really the request needs to be two-part:
Allow overlay DSFs to change the underlying mesh heights of the global scenery underneath them.
Provide an interface and exporter in WED to export the new “mesh modifier” added to the scenery in point (1).
The first change is a change to X-Plane and its file formats; the second one is to the scenery tools.
I don’t blame authors for filing the bugs against WED – as far as authors are concerned, WED is their interface to the scenery system; they want to see something new in WED, and if I do (1) and not (2), the job is not done.
But…the bug base is also my todo list, and having an item on the wrong todo list is a good way for it to get “lost”. If I look at mid-term feature requests for the scenery system in X-Plane, I will not find anything in WED.
I haven’t figured out what I am going to do with this, but one possibility is to simply move all valid feature requests on the underlying scenery system out of the WED bug base and into the X-Plane one. This will have the side effect of taking them private, but if the feature request is a legitimate one, I don’t think the original poster will need to provide more information.
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:
We have no idea how many airports have their taxiways broken by this bug.
Authors have no easy way to detect this problem, other than re-testing every airport at every rendering setting.
Even if an airport looks okay at all rendering settings, future rendering settings may cause the problem.
This is too much uncertainty to solve ‘by hand’. So my plan is:
Undo the code change for 1031. YMML and friends comes back.
Develop validation code in WED to detect this kind of authoring error.
Ship that version of WED so new authoring work will be checked.
Run the WED code on all airports and make a list of ones that need repair.
Fix all of the known problems in the airport gateway.
Redo the code change so X-Plane is correct.
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:
X-Plane 10.30: you need to create a symlink if it doesn’t work
X-Plane 10.31: no need for a symlink because we won’t depend on libudev at all
X-Plane 10.x: X-Plane will ONLY require libudev when you are using the Oculus Rift
