Author: Tyler Young

What Would Make the ATC System Better?

This may come as a shock to you, but… we hear a lot of complaints about the X-Plane 11 ATC.

I have good news: We want to improve the ATC!

The problem we’re facing is that a lot of the feedback we get is indistinct—hearing “ATC sucks” doesn’t help us understand how we could do better. So, here’s what we’d like from you: Tell us the specific issues you have, or the specific features you’d like to see implemented. At this point, we can’t promise a timeframe for any given improvements, but we can promise to consider everything you say.

Please note: Any comments on this post that don’t directly relate to ATC will be deleted. Moreover, please don’t slag on other people’s wishlists—arguments against other people in this thread will not inform our decisions about how we prioritize this stuff.

Posted in Air Traffic Control by | 240 Comments

Linux users: Please don’t run X-Plane with sudo!

TL;DR: Running X-Plane with sudo is a bad idea. Instead, create proper udev rules (per this and this).

During the 11.10 beta, I’ve gotten a lot of bug reports from Linux users who report that their keyboard is being recognized as a joystick. This is… sort of a bug, but mostly intentional.

(If you’re not a Linux user, this won’t apply to you… but it will bore you! 😉 )

Background: What changed?

On Linux, prior to X-Plane 11.10, we were very picky about what USB devices we considered to be a joystick: we required a device to present a so-called “absolute” axis (in contrast to a “relative” axis like a mouse uses). The downside of this is that it prevented home cockpit builders from creating button-only hardware.

So, in 11.10 and beyond, we relaxed the requirements: if a USB device presents us with either an axis, button, or hat switch, we’ll treat it like a joystick.

The problem with this policy seems obvious: keyboards have “buttons”! Like, 104+ of them!

The reason we didn’t worry about this is that the keyboard is only accessible (as a USB device) to programs running as root. So long as X-Plane runs as a normal user, it doesn’t even have the option of treating the keyboard as a joystick.

Why do people run as root?

The impetus for running as root (via sudo) is simple: if your Linux distro doesn’t recognize your joystick hardware as something that should be available to normal applications, running as root is a brute-force way to let X-Plane use your joystick.

Let me say emphatically: This is a bad idea.

Especially with early, buggy betas, running as root makes it possible for X-Plane to do way more damage to your system than would ever be possible as a normal user. Consider the unlikely—but possible!—scenario where somebody made a typo in the code which inadvertently tries to delete a system folder. There are two possible outcomes here:

  • If you’re running as a normal user: Nothing happens. The operating system refuses to let X-Plane hurt your system.
  • If you’re running as root: The operating system silently obeys. You curse X-Plane for breaking your system.

Running X-Plane as root is like giving a blank check to every cashier you buy something from—it’s way more power than they need to do their job, and it’s liable to burn you at some point!

The Right Way™ to let X-Plane use your joystick

As described in the latter half of this old dev blog post, you don’t have to run with sudo. Instead, you can create udev rules to tell your operating system to let normal applications use your joystick. The GUI tool linked at the end of that post makes it even easier.

(Some users found the instructions there confusing; this post on the Org might help.)

Remember that after you create your rules, you can even submit them to your distro to make life easier for other flight simmers!

There’s one hitch: after running with root, your file permissions (especially your prefs) may have gotten screwed up. This can be fixed from the terminal by making your normal user account the owner of your X-Plane directory, like this:

$ sudo chown -R <username>:<username> /path/to/X-Plane/

(So, in my case, my username is tyler, and X-Plane is installed to ~/Documents/X-Plane/, so I’d run $ sudo chown -R tyler:tyler ~/Documents/X-Plane/.)

Now, to those of you who have been running as root… “go, and sin no more”! 😉

Posted in Really Really Really Really Boring Stuff by | 14 Comments

Improving AI Aircraft

AI planes face two major issues in X-Plane 11:

  1. AI aircraft are often way more resource-intensive than they need to be. Users are fine paying a performance penalty to load, say, a super detailed 3-D cockpit model for their own aircraft, but for AI planes, where you’re never going to be in the cockpit, there’s no reason for that sort of thing. A significantly “dumbed down” version of the same aircraft would allow users to load more AI planes at once, with no visible downsides during normal use.
  2. Many aircraft, for one reason or another, simply won’t function at all when used as AI planes. This is most commonly due to one of two issues:
    • reliance on third-party plugins (which only work for the user’s plane)
    • lack of support from X-Plane for flying aircraft like this (for instance, the X-Plane AI doesn’t know how to fly gliders, seaplanes, or rockets)

As a user, this is really frustrating, because it’s difficult or impossible to know in advance which aircraft will work as AI planes and which will either a) just sit on the runway, never able to take off, and/or b) tank your frame rate.

Coming in X-Plane 11.10: AI-Only and User-Only Aircraft

In the upcoming X-Plane 11.10 beta, we’ve added two new options to Plane Maker’s Author window: “supports user flight” and “supports AI flight.” By default, all aircraft support user flight, and do not support use as AI aircraft.

If a plane is configured for AI flight only, it will never be shown in the normal aircraft grid—only in the AI aircraft window.

If a plane is configured for user-flight only (or if it’s a pre–11.10 aircraft with no “supported flight type” info), it will be hidden in the AI aircraft window by default, but for the sake of backward compatibility with old planes, users will still be able to reveal them by checking a box labeled “Show aircraft without AI support.”

The upshot for aircraft authors

In the Glorious Future, we envision third parties shipping two versions of their aircraft:

  • one marked user only, which include all the bells and whistles, plugin-enhancements, and as much detail as possible
  • one marked AI only, which is stripped down for performance, only using plugin enhancements that have been tested in AI configurations.

The result will be a faster, more consistent, less error prone experience for users.

Posted in Aircraft by | 19 Comments

New SDK Features Coming in X-Plane 11.10

The upcoming X-Plane 11.10 release (and before you ask, we’ll let you know as soon as we have an ETA! 🙂 ) will include Version 3.0 of the X-Plane SDK (XPLM).

NB: The code samples linked below will not work yet—in part because X-Plane 11.10 isn’t in beta yet, and in part because we haven’t updated the sample code downloads with the new XPLM300 headers. But, that doesn’t mean you can’t look at the code itself right now!

There are a handful of really important features here for plugin developers:

  • Instanced drawing (via the new XPLMInstance header). This is a really important one for improving plugin drawing performance. More info on the theory behind this in Ben’s recent post. The good news for developers still working on X-Plane 10 plugins is that we’ve created a “wrapper” to provide backward compatibility with old versions of the SDK. Using the wrapper, you don’t get the performance benefit that you’d see in X-Plane 11, but you’ll at least be able to use the same API. See the sample project here.
  • Map APIs (via the new XPLMMap header). Based on our RFC, this provides an interface for drawing text labels, PNG icons, and arbitrary OpenGL within the X-Plane 11 maps. See the sample project here.
  • Two minor features for menus (in the XPLMMenus API; see the new menu SDK sample for examples):
    • Aircraft-specific menus. Plugins that get loaded with the user’s aircraft will now have access to XPLMFindAircraftMenu(), to which you can append new menu items or submenus.
    • Menu items that show keyboard shortcuts. When you add a menu item via XPLMAppendMenuItemWithCommand(), if the user has a key bound to that command, the key will be displayed on the right-hand side of the menu, just like X-Plane’s native menus.
  • More joystick axes & buttons, to match X-Plane 11.10’s support for 20 USB devices (up from the previous cap of 10).
  • Lots and lots of new features for plugin-created UI in the XPLMDisplay API, including:
    • Support for styling windows like the built-in X-Plane 11 windows (sample project here)
    • Support for “popping out” windows into first-class OS windows (demoed in the same sample project above)
    • Support for automatic UI scaling of all drawing in your window (this comes for free in all windows created with XPLMCreateWindowEx that are compiled against the XPLM300 API)—this means users with hi-DPI/4k monitors who have set a 150% or 200% scale for the X-Plane UI will get the experience they do with built-in windows.
    • Support for windows that automatically “stick” to certain edges of the screen, via the XPLMSetWindowGravity() API (sample project here)

Just to be 100% clear, to get any of these features (with the exception of the backward-compatibility wrapper for instanced drawing, of course), you’ll need to compile against the XPLM300 API.

[Edited to add:] Using the XPLM300 API is 100% optional. Old plugins will continue to function, and you could even write new plugins and compile them against the old API (I’m not sure why you would you want to…), and they’ll work in X-Plane 11.10 and beyond.

Posted in Plugins by | 27 Comments

RFC: Plugin-Drawn Map Layers in X-Plane 11

We’re working now on updating the map drawing SDK for compatibility with X-Plane 11.

This post is a request for comments from programmers who write plugins that used to draw to the map—it is not a place for general feature requests for the map, or for off topic comments. (And off topic comments will be deleted.)

Background: What broke the map drawing in the first place?

Long story short, the map has changed drastically since the X-Plane 10 version—it didn’t just get a fresh coat of paint.

The biggest obstacle to backward compatibility comes from the fact that we now use an honest-to-God cartographical map projection for map coordinates. Moreover, the map projection changes for different map types—the normal map UI uses a transverse Mercator projection, while the GPS units use a stereographic projection. For that reason alone, just “splatting” old drawing code on top of the new map would not give you the results you want… the old OpenGL local (x, y, z) coordinates do not have a straightforward mapping to the new projected latitude/longitude locations.

A second major change is the fact that the map can now rotate to match the heading of the user’s aircraft. Unless you like the possibility of your map labels being printed upside down, this requires awareness of the map’s rotation and the fact that north isn’t necessarily “up”.

The final big change comes from the draw order. The map is now very strongly divided into layers, and we draw in 3 stages:

  1. Backgrounds (e.g., terrain)
  2. Icons (e.g., airports, NAVAIDs, etc.)
  3. Labels

An individual layer can draw in any or all stages. (For instance, the airports layer draws both airport icons and labels for each icon.) We draw each stage from the bottom layer up, beginning with the terrain at the bottom, then the NAVAIDs & airports somewhere in the middle, and then finishing with the aircraft at the very top. This layering ensures that bigger or less important elements don’t cover up smaller or more important elements—your aircraft, for instance, will always be visible (and selectable), even if it’s in the exact same place as a fix or NAVAID. Likewise, the label for your element will always be visible even if the actual icon is obscured by something above it. (In practice, of course, readability is going to be poor if you have labels overlapping, but that’s not really solvable without much more powerful cartographical tools than we have now.)

While it’s not essential that plugin drawing code respect the layering draw order, it would certainly be nice—it would allow you to ensure that a) your plugin-drawn layer doesn’t cover more important info, and b) less important info doesn’t cover your layer.

Proposed API

With all that in mind, our proposed API for map drawing looks like this:

  • Plugin code would call the SDK to create a new map layer. To do so, you would provide:
    • An optional drawing callback for OpenGL drawing (which would be layered beneath all built-in icons & text, but above things like X-Plane’s terrain drawing).
      • OpenGL drawing here is more or less a “free for all,” with one exception: manipulating the Z buffer is not allowed, due to our reliance on the Z buffer as a means of preserving layer ordering.
    • An optional icon callback, where you would provide a set of PNG icons to be drawn, along with their heading, opacity, etc., and X-Plane would “splat” them onto the map above all built-in icon types except the aircraft
    • An optional label callback, where you would provide a set of strings for X-Plane to draw above all built-in labels except the aircraft label
    • An optional “prepare cache” callback, called whenever the map’s total bounds change (e.g., when the scenery loader loads new DSFs). This allows you to keep your drawing callbacks fast, since you can cache only the data you need for drawing in the current area.
    • A flag to indicate whether you’d like your new layer to be disablable from the UI (if so, we would add a checkbox to the right-hand sidebar like we have now for the flight path and compass rose)
  • Drawing, icon, & label callbacks would receive:
    • The currently visible bounds of the map
    • The current zoom level of the map
    • The map units per unit of UI coordinates (useful for drawing text at a fixed size regardless of map scale)
      • If your layer is drawing in the standard X-Plane map window, this is map units per boxel; if you’re drawing within the GPS unit, it’s map units per “virtual device pixel,” whose size in real screen pixels is of course fluid since the user can move the camera relative to the GPS in the panel.
    • The map’s current mode (currently one of either sectional, low enroute, and high enroute)
    • An opaque handle that provides access to the new projection APIs. The projection APIs would provide the following functions:
      • project a latitude & longitude into map coordinates for drawing
      • unproject an (x, y) pair of map coordinates into a latitude & longitude
      • get the scale, in map coordinates, of 1 meter at a given (x, y)
      • get the heading (in degrees clockwise from “up”) corresponding to north on the map for a given (x, y)—this is necessary since the X-Plane 11 map can be rotated to match your aircraft’s orientation
  • Relative ordering of plugin-created layers would not be guaranteed. So, if you had two plugins which drew the same icon in the same place, but one drew in red and the other in blue, we would make no guarantees about which color the user saw. (And, indeed, some users may see red and others may see blue.)

Questions we have

While the proposal above meets what we believe the needs of third-party developers to be, we almost certainly haven’t considered every use case for this API. (And it’s possible we’re missing important features even for the use cases we have considered!)

To that end, here are some question you, dear plugin developer, can answer for us:

  • What’s your use case for the map drawing API?
  • Does the proposal above sound workable for your use case? (If not, what’s missing, or what would you change?)
  • Do you like the idea of allowing plugin developers to specify whether their new layer is togglable from the standard map UI? (If not, why, and what policy would you like to see instead?)
  • Do you have a use case for click selection and click-and-drag functionality in your plugin-created map layers? (This isn’t on the table for the initial update to the map API, but it’s a possibility for future updates.)
Posted in Uncategorized by | 32 Comments

We’re hiring!

We’re looking to add two developers—one junior, one senior—to the Laminar Research team this spring.

As a member of our team, you would:

  • Work on stuff that matters. Real pilots fly safer because of training in X-Plane, and real aerospace organizations (like Boeing, Cessna, and NASA, to name just a few) prototype aircraft in X-Plane before they build them in the real world.
  • Work on a product that millions of people will see. You’ll get feedback from users, and that feedback will drive future development.
  • Have tremendous input on the direction of the product. Because X-Plane is an exceedingly small team, every team member has a lot of say about what we work on and how we make the simulator better for our users.
  • Set your own schedule. As far as we’re concerned, if you’re shipping features and fixing bugs, it’s your business when you do so.
  • Work remote. No commute, no cubicles, nothing to impede you from doing great work. (But the rest of the team is just a Skype call away!)
  • Work on a variety of technologies and products. At various points, you might work on X-Plane, Plane Maker, WED, the X-Plane installer, the Scenery Gateway web app, or even the web site.


A qualified junior candidate will:

  • Have a computer science degree.
  • Be a quick learner. We expect most of what you need to know (beyond computer science fundamentals) to be learned on the job.
  • Have the self-discipline to work from home and set your own schedule. (It’s not for everyone.)

In additions to the above, a qualified senior candidate will:

  • Have experience shipping major features in production applications with minimal oversight.
  • Have specific experience relevant to X-Plane. There’s no exhaustive list of skills we could use, but some possible examples include:
    • Real-time graphics
    • Real-time C++ development
    • Mobile development
    • Game development
    • GIS data processing
    • Networking
    • The X-Plane plugin system

How to Apply

Send an email introduction to me that includes:

  • Which position you want to apply for
  • A brief overview of a project (or projects) you’ve enjoyed working on
  • Discussion of projects you have not enjoyed working on

The introduction is really just a means for me to get a handle on who you are as a developer, so do not stress over it!

My email is my first name at Please do not attempt to apply in comments!

(Not sure if this is a good fit for you? Email me anyway and we can talk. 🙂 )

Posted in Uncategorized by | 16 Comments

X-Plane Usage Data

When we put out the request for comments on publishing X-Plane usage data four and a half months ago, I had the best of intentions for creating nice, web-based, automatically-published, interactive graphs & charts with all the data we have.

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_categoriesFirst vs Third Party Percent third party flights


CPU_cores flight_controls

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.

Posted in X-Plane Usage Data by | 24 Comments

Giving X-Plane More Info About Aircraft

One of the new features in Plane Maker 10.40 is a variety of classification information available for aircraft files, found in the Standard > Author window.

These fields are not currently in use in the X-Plane user interface, but we do plan to use them in the future—we want to do away with clunky folder-based browsing of aircraft. Instead, we want to allow users to browse & search through their aircraft in a much more flexible way: by aircraft name, manufacturer, category (general aviation, airliner, glider, etc.), and design studio.

So, for instance, you might want to see just the planes that were developed by Carenado, so you would select Carenado from the aircraft studio dropdown. Or, you might want to see just the general aviation planes built by Cessna, so you’d select General Aviation from the category dropdown and Cessna from the manufacturer dropdown. Or, you might want to search for all the aircraft with “747” in their name, and see your 747-100, 747-400, etc.

We think this will be a serious improvement over folders, which allow you to organize your aircraft in only a single, fixed way.

But, before that happens, we’d like to get as many aircraft authors on board as possible—we can’t know, for instance, which design studio created an aircraft unless you add this info to your ACF files.

So, grab 10.40, open Plane Maker, and add this classification information to the aircraft you develop!

(As an aside, you might be wondering… what’s the difference between the aircraft’s “author” and “studio”? The idea here is that the “studio” is the group producing the aircraft—you want your “studio” to stay consistent for all the aircraft your group produces, while the “author” field credits the actual people involved in the plane. Your studio might be “Amazing Sim Planes,” while your “author” field might be something like “Jane Doe, flight model; John Doe, 3-D modeling; Jack Jones, texturing.”)

Posted in News by | 24 Comments

Let X-Plane Tell Us How You Use X-Plane

One new addition to Version 10.40 is almost guaranteed to be controversial: at the user’s discretion, we now collect anonymous usage information.

Before you light your torch and grab your pitchfork, let me explain why we have not become the next Spyware Kings.

Whose information are we collecting?

The X-Plane 10.40 installer has a screen to explain the data collection, and a checkbox to opt-out. If X-Plane is already installed, you can toggle data collection on or off using the Operations & Warnings window in 10.40 and later.

We will only collect usage information from users who have that checkbox enabled. If you upgraded to v10.40 from an older version of X-Plane, for instance, the checkbox in the Operations & Warnings window is disabled by default.

(But, read on to find out why you should go turn it on!)

What does “anonymous usage information” mean?

In our case, we collect two main types of information:

  • system configuration (including your operating system, CPU model, graphics card model, amount of RAM, what language you’ve selected, and so on)
  • X-Plane usage (including which aircraft are flown, which airport you start at, and so on)

This information is 100% anonymous. Essentially, all we ever learn is that some user, somewhere was running Windows with a Core i7 CPU, 8 GB of RAM, etc. and they flew the C172 from KBFI. We cannot trace this information back to a specific person.

Will I be contacted or be spammed if I participate?


Since everything we collect is anonymous, it obviously does not include contact information like your name or email address. We can never use the information collected to contact you in any way: no marketing, no spam, no way to bug you.

Why does X-Plane want this information?

In essence, your usage data helps us make better decisions about the future of X-Plane.

For instance, if we found that 50% of users were running 10 year old machines, we would need to think long and hard about increasing the system requirements in future versions.

Similarly, if we found that only 10 people ever flew a particular aircraft, we could conclude that users weren’t very interested in it, so we probably shouldn’t create a new aircraft that was very similar. Likewise, if 25% of flights involved the 747, we might decide that people really like big airliners, so we should probably create another.

This is roughly a billion times better than the way we currently make decisions about this type of thing (both in terms of hardware support and sim features). The current model looks like this:

  1. Make a guess about what users want
  2. Argue with the other developers who guessed differently
  3. Ship something that users may or may not actually like

I can’t stress how much having actual data will improve our ability to make X-Plane the product that users really want.

Why you should participate

Sending this anonymous usage information is like casting a vote—in this case, a vote for us to support the way you use X-Plane. When you send your usage information, you cast your vote for us to support your hardware configuration, to build more of the planes you like to fly, or to improve the airports that you like to fly at.

Just like in electoral politics, you have every right to abstain. But abstaining means we’ll hear other people’s voices and not your own.

If you’d like to participate, you just need to do the following:

  1. Get the 10.40 update and launch X-Plane
  2. Open the Operations & Warnings dialog
  3. Check the box labeled “Send anonymous usage information to help make X-Plane better.”
Posted in News by | 47 Comments