Whenever we encounter a problem like this, we try to pull back and take the humans out of the process. Out of that philosophy, let me present to you:

The new, always-up-to-date X-Plane usage data “dashboard.”

Like our blog posts, this is based on data collected from paying users of X-Plane 11 who have opted-in to data collection.

Unlike our blog posts, though, this updates daily based on live usage of the simulator!

Have a look, and if you spot any bugs or want to see something else, let me know in the GitHub project’s issue tracker.

The post Usage Data Never Goes Out of Style appeared first on X-Plane Developer.

X-Plane collects diagnostic & usage data on a strictly opt-in basis. All information we collect is anonymous; it does not include contact information like your name or email address. We share the aggregate usage data with the community but we do not share or sell (or even have direct access to) the raw data.

Below is 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. Tyler did a lot of work to consolidate obvious duplicates, but aircraft authors, please please please set this up correctly at the start and then leave it alone! It will make tracking data on your specific aircraft easier for everyone.

Aircraft

Hardware

VR

Since 11.20 went final, 2.65% of all users have flown at least 1 flight using VR hardware.

Raw Data

X-Plane 11 aircraft data

X-Plane 11 hardware data

The post Usage Data as of June 2018 appeared first on X-Plane Developer.

We’ve filtered out demo users again, and this information is for the entire life of X-Plane 11 (1 Nov 2016 to 21 Nov 2017) since we’ve never published airport data before. I’ve only pulled the top 50 airports for this list, but we track 11,281 locations.

The post X-Plane 11 Airport Usage Data appeared first on X-Plane Developer.

It took me a bit longer than I would have liked to compile the graphs while working around the 11.10 beta, but we now 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).

• Aircraft Data: X-Plane 10  X-Plane 11
• Hardware Data:  X-Plane 10  X-Plane 11

The post Usage Data Update for November 2017 appeared first on X-Plane Developer.

The reason for this is that coded instrument flight procedures (CIFP) come from very reliable sources – Jeppesen or LIDO (depending on whether you get your data updates from Navigraph or Aerosoft), while the runways on X-Plane’s airports come from a community driven, open database: The X-Plane airport gateway.

Unfortunately, the airport gateway community is not always fast when it comes to runway renames or airport expansions, which happen all the time all over the world. The most common reason for a runway rename is a shift in magnetic variation: Runways are named for their cardinal direction relative to magnetic north. While the runway’s orientation with regard to true north is fixed^{[citation needed]}, the orientation measured against magnetic north changes over time, as the magnetic pole moves and local magnetic declination changes. Now when the magnetic course of runway 11L changes from 114 to 115 degrees, airports paint new numbers on their runways. 11L-29R becomes 12L-30R. Jeppesen knows about this and changes the runway name in all their data, which ends up in a data update for X-Plane. Meanwhile, the scenery author community over at the airport gateway of course has more exiting things to develop then a runway rename.

To make things worse, runway renames are super annoying in WED. After you renamed the runway from 11L to 12L, you had to go through ALL your flows, ALL your taxiroutes, and ALL your airport signs to change the name EVERYWHERE.

In the past, we have partially solved this problem by running mass renames of runways in the gateway database rather than through WED. If you see a change on an airport made by a user named “WEDbot” (like at this airport) that is usually such a batch-rename.

With X-Plane 11.10 and WED 1.7 there are some big changes that greatly improve the interaction between X-Plane airport data, navdata, WED, and the airport gateway.

Easy runway rename in WED

WED 1.7 has a function that changes all flows, routes and signs for you when you rename a runway end. This makes bringing an airport up-to-date a nearly foolproof operation even for a WED-dummy like me. You don’t need to be a scenery wizard to simply fix an airport anymore.

Silent runway rename in X-Plane

If you have navdata from Aerosoft or Navigraph, and a runway in the X-Plane airport matches a runway coming from the navdata, but the name has changed, X-Plane 11.10 now silently renames the runway at runtime for you. Which means, even if a 11L is painted on the runway, the FMC can load the procedure for 12L and get you there. This only works if the scenery is properly georeferenced and the runway is actually in the right spot – if the scenery was made incorrectly and the runway is not at the right coordinates, this obviously doesn’t work.

Silent threshold fix in X-Plane

Not all scenery authors correctly place displaced thresholds. A bit of confusion exists over when to use the white arrows or the yellow chevrons – and which counts into the runway length and which doesn’t. I teach my student pilots “the only thing you can do on yellow chevrons is crash – anything but crashing on that area is illegal.” Hence this area doesn’t count for runway length. Again, if you work off a properly georeferenced orthophoto, you won’t have any problems. Unfortunately, if you misplace where the (displaced) threshold is, this coordinate problem can feed back into the instrument procedures of this runway. For example, for many non-precision approaches the MAPt of the procedure coincides with the runway threshold, so if those coordinates are off, so will be your missed approach point. With X-Plane 11.10, if a runway in the airport scenery matches a runway coming from your updated navdata, but the threshold is laterally offset from where it should be according to instrument procedure data, X-Plane silently moves the threshold coordinates the GPS/FMS works off to the correct location. This works if the scenery is “good enough” in that the majority of the runway pavement is where it should be, and the thresholds are only off in the direction of the runway. If the whole scenery is ill-referenced, meaning the runway is off other than along its major axis, this obviously doesn’t work.

Silent and not-so-silent feedback

If you have enabled anonymous data collection in X-Plane, whenever your X-Plane silently applies a runway name or runway threshold location fix in the background, it also sends a packet of data to our analytics server, telling us the airport you were approaching and what was up with the runways. Collecting this data from a wide range of X-Plane 11 users will allow us to generate a heatmap, i.e. the most important airports that need the gateway communities’ love. Note that this data is collected only if you are running navdata that is current – we are not collecting reports based on historical data.

Only if both of the above fail, which means the airport has both a problem with its runway numbering and is ALSO poorly georeferenced (runways are in the wrong location geographically) the situation is beyond fix for the new runway logic. Only in this case you will see the dreaded dialog, because the runway simply does not exist in X-Plane, at least not where it should be. In this case, you will be able to submit an automatic report to the gateway website if the problem exists with current navdata. Note that this dialog will come up whether you have enabled data collection or not – but you can still chose to close it without actually posting the report if you don’t want to.
Only this kind of “all is lost” reports are actually visible on the gateway website and the XSG bug database. This allows artists to see the only airports that are actually so outdated that they cannot be fixed automatically. The automatically fixable scenery errors no longer clutter up the gateway airport bugbase.

Any downsides?

The downside to all these changes is that they all actively work to keep the X-Plane default scenery up to speed with the airport changes in the real world. This means that over time, as our global airports follow the real world in terms of runway renames, airport construction, expansions, etc… it will become less useable without up-to-date navdata. That’s the price we have to pay for “as real as it gets”.

Break ALL the scenery!

Poorly georeferenced scenery has a problem beyond affecting the missed approach points of non-precision approaches. It also affects the ability to use the new SBAS (satellite based augmentation system) approaches that are comparable in accuracy to ILS. I always prefer to fly the LPV approach if given the choice. However, the FAS block (final approach segment) comes from the navdata, which means it guides you precisely to where the runway is in the real world. If the X-Plane scenery is poorly referenced, the approach will dutifully fly you into the grass in X-Plane, if this is where the runway would have been in the real world. This is obviously a problem for serious training scenarios. Therefore, X-Plane 11.10 can be started with the commandline option –accurate_runways which will dynamically rewrite the actual scenery in X-Plane after loading an approach, both moving the runway into the correct geo-location and also changing the numbers written on the runway if needed. This obviously only works on default scenery with the procedurally generated runway textures. It will not change custom scenery that uses draped polygons for photorealistic runway textures. Moving the runway into the correct location will obviously also disconnect it from any incorrectly placed taxiways. Also, using this option increases load times for selecting an instrument procedure significantly, since it has to rebuild the airport scenery. So this option is really only there to help you keep limping along with broken scenery, if your operation absolutely requires accurate runways and you can live with some broken taxiways. It is therefore not available as an “official” setting. Do not come to us to complain about the jarring results – make a proper fix in WED instead! The results can be quite disruptive, but at least the approach won’t guide you into the grass:

The post Break ALL the airports! Correcting runways in WED 1.7 and X-Plane 11.10 appeared first on X-Plane Developer.

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).

• Aircraft Data: X-Plane 10   X-Plane 11
• Hardware Data: X-Plane 10   X-Plane 11

The post Usage Data for X-Plane 10 & 11 appeared first on X-Plane Developer.

Unfortunately, I’ve been head-down working on top-secret features for X-Plane Desktop (believe me, when you see this stuff, you’ll understand why!), and my analytics data project has just languished (and will continue to languish for many months more as I finish the Desktop features).

So, after a gentle kick in the pants, I’m publishing the data as I have it. It’s not pretty, but I think it will still be useful to third-party developers. We have a handful of easy-to-digest charts, plus a whole bunch of raw data at the bottom of the post for those that are interested.

Note that all data in these charts are for users of the full version only—I’ve filtered out demo users.

Do let me know in the comments if you have questions about the data!

Aircraft

Hardware

Raw Data

There are two files here: hardware data, and aircraft data. Each contains all the information we have since September 2015, for paying customers only (no demo users). I’ve provided two formats for each file: an XLS, and a simple CSV.

• Aircraft usage data: XLS CSV
• Hardware data: XLS CSV

The post X-Plane Usage Data appeared first on X-Plane Developer.