Category: RFC

RFC: X-Plane Usage Data

This is a “Request for Comments” post—please discuss the proposal in the comments. Per our standard procedure, if you comment asking about the Oculus Rift, your comment will be piped to /dev/null.

X-Plane started collecting anonymous usage data in version 10.40. I used some of that data to compile this infographic you might have seen around the internet. It’s fun and colorful and has some interesting tidbits of data. However, just because I thought that those statistics were noteworthy doesn’t mean that you did.

So, is there anything else you, as third party developers, want to know? Is there information missing from the infographic that would help you decide where to put your development energy? Do you want more specific details about anything mentioned in the infographic? We have all kinds of statistics available, from what languages are used the most, to the most popular screen resolution.

If you’d like to have more information, how often would you like to see it, and what format would be the most helpful? Spreadsheets are easy and can be processed often, and we could throw some graphs in there to make them less boring.

Any of this sound appealing to you? Let us know in the comments!

Posted in Development, RFC by | 30 Comments

RFC: Dataref-Driven Library Regions

I have a working prototype of a proposed modification for X-Plane 10.40: dataref-driven library regions.

The idea is simple: you can define a region in a library pack, and X-Plane will only load those art assets when datarefs written into the library.txt file evaluate to true.

One of the main usages for this is to implement seasonal or winter scenery add-ons that don’t require rebooting the sim to take effect. Right now if you want to change the look of the scenery you either:

  1. Write a script to replace files inside X-Plane.  This makes updating X-Plane tricky, but it lets you mod anything.  Of course, some of those mods may not work in future versions.
  2. Create a custom library pack that replaces library paths for the default art.  This requires  reboot to take effect but doesn’t affect updates and is stable.

With this extension, method 2 can be done without a reboot.  The custom library art assets are put in a region and the region is set to only be available when certain datarefs are set to certain values.


Changes to the datarefs require a scenery re-load to take effect; that’s the cost of being able to fully change the art asset in the library.  This does allow for a lot of flexibility, however – whole objects can be added or removed based on the date, for example.  For seasonal use, if the user can decide on a season before flying, the reload should not be a facotr.

Textures vs Library Paths

The original proposal was to allow textures to be swapped by dataref. I changed to library paths because a number of the existing seasonal/winter add-ons for X-Plane change properties of art assets other than the textures; for example, they change specularity values or add normal maps that were not otherwise present.  Only changing the library art asset allows for complete customization.

Proposed Syntax

The new syntax is a single library.txt line:

REGION_DREF <dataref> <comparison> <value>


REGION_DREF myplugin/use_snow == 1.0

Datarefs can come from the sim or a plugin; all six conditionals (< <= == != > >=) are available.  If more than one REGION_DREF line is present, all must evaluate to true to use the region.

Request For Comments

Please use the comments section to comment on this particular proposal. I’m going to be a bit fascist and nuke all off-topic comments.  This is about a specific proposed feature, not a general news update.

I have working code for this; if you’d like to try a developer build, please email me.


Posted in File Formats, RFC by | 12 Comments