X-Plane 11.02 Release Candidate 1

There's a new 11.02 release candidate available - if you had the 11.02 beta, you'll be notified to auto-update.  In a break with previous policy, this RC is available now on Steam as a beta, despite us not having had time to kick the tires.  (Normally we wait 24 hours to make sure the beta isn't nuclear before posting it to Steam.)

Release notes here. This build has some work Sidney did to improve pauses and stutters when loading orthophotos. Also, by request from X-Plane users at FSConn: a new art control gives you writable access to the fog ratio (for fog hackers) - set "fog/fog_be_gone" to...well, whatever makes you happy. I can't promise this art  control will be around forever, but right now it works and is writable (unlike "fog/std_deviation_cutoff", which is controlled by the sim to match real world observations).

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News | 48 Comments

Flightsimcon Videos

We've gotten a number of requests for video of the conference. Chris just posted these on our Youtube channel:

And the accompanying slides:

This is the original of Chris's VR demo - he looks super dignified with the HMD on.

Finally, here's video of the panel discussion from Saturday afternoon.

This one wasn't recorded by us.  There was a "serious" video camera at that event, so if there's video with a direct feed from the mixer, I'll post it.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News | 80 Comments

Flightsimcon 2017

I just got back from Flightsimcon (I live close enough to Hartford that it's a day trip for me), but the show is still going on, and as you might have heard, we have X-Plane set up with built-in VR at our booth -- you can try it! Austin, Philipp, Chris, Marty, Alex and Jim will all be there tomorrow, so stop by if you can.

If you're local, stop by tomorrow - seeing the MD-82 cockpit in real stereo 3-d is something else. I've been working on VR support (on the rendering side) for the last few weeks and it's really made me appreciate what our art team does.

I also wanted to say thanks to everyone there who has been supporting X-Plane, and also to the rest of the LR team who didn't attend but who did the hard work that made today's announcements possible.

There is video of our presentation - if there isn't a better recording, Chris taped the thing, so we'll get it posted probably some time this week.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News | 46 Comments

WorldEditor 1.6 Release Candidate 1 Is Here

Posted a few minutes ago: WorldEditor 1.6 release candidate 1.  RC1 has a bunch of key bug fixes, is gateway-ready now, and can edit X-Plane 11 truck routes.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News, Tools | 37 Comments

Blender Exporter Testers

Ted and I have been working on a new version of XPlane2Blender for Blender 2.5. The new version mostly focuses on bug fixes and optimizations to get perfect WYSIWYG output from Blender to X-Plane with optimal OBJ code.

If you use the version 3.3.x of this exporter and would like to try test builds, please email me. We have a suite of test cases that we run the exporter through to confirm that it is operating properly, but it's also useful to run it on real-world examples to see if there are cases we missed.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Tools | 12 Comments

Roll Over Beethoven (and Pilot’s Head)

Long overdue, coming in 11.02 beta 2:


That's a new dataref that (finally) lets plugin authors tilt the pilot's head.

Previously this had to be done by manipulating the multi-monitor view offsets. That method worked (barely) but doesn't work with multi-monitor in v11.  The new dataref is multi-monitor friendly.

(The new dataref is also FMOD-sound-friendly -- that is, when you roll your head over you'll hear sounds above you out your left ear, as expected.  Monitor offsets do not do that - only the pilot's true virtual head position affects sound.)

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development | 17 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.)

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Uncategorized | 32 Comments

FMOD Video Tutorial

We have a new video tutorial on using FMOD to add custom sounds to X-Plane 11. This simple tutorial shows how to add a snapshot and an event in FMOD.

The video also has a permanent home on the video page of this site, and on the X-Plane YouTube channel.

As always, let us know your thoughts in the comments and if you have requests for other tutorials. I'm starting to get the hang of creating movies, and if you don't troll me too hard about the quality I might make more. 😉

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft, Screencasts | 12 Comments

Suddenly surrounded by heliports? How to configure airport criteria for aircraft

With X-Plane 11.02 the built-in GPS and FMS units for X-Plane 11 aircraft will also display heliports and seaplane bases. While this change is obviously needed badly for the helicopter flying community, improperly configured fixed-wing aircraft might suddenly feel themselves confronted with unsuitable options in the nearest airport selection pages and on the moving map.

Filter criteria

Every X-Plane aircraft has three parameters for airport and runway filtering that can be used to configure the moving map. These settings have existed for a long time, influenced which airports were displayed on the moving map, and kind of worked with the X-Plane 10 GPS as well. X-Plane 11 completely broke those settings for airplanes using the new X430/530 GPS, and not all aircraft authors go through the trouble of setting them up correctly.

X-Plane 11.02 correctly filters airports for GPS and FMS use as well as for the moving map based on these parameters. Because the GPS now also displays heliports and seaplane bases, it is important to set these filter parameters correctly in Plane Maker, to prevent unecessary clutter on the map.

The three settings are:

  1. Only Airports on Map - If not checked, the GPS and moving maps will show helipads and seaports. Check when you do not want those to show up in the nearest airport list on the GPS
  2. Only Paved Runways on Map - If not checked, the GPS and moving maps will show airports with no solid runways like grass, gravel and water surfaces
  3. Minimum Runway Length to Show on Map - This will filter out airports where the longest runway is shorter than this distance

Note that the these settings work on a per-airport basis. That means:

  • At an airport with both runways and helipads, the helipads will still be shown regardless of setting.
  • At an airport with both paved and grass or water runways, both runways will still be shown.
  • In other words, airports are filtered out if they ONLY have helipads, or ONLY soft runways
  • For seaplanes, leave the "Only Airports" box unchecked but enter a runway length number in order to supress the heliports.

If you already set these parameters in the past and they worked in X-Plane 10, there's nothing for you to do. If you never bothered to set them, and suddenly see places inappropriate for landing show up in your built-in GPS, that is why.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft, Aircraft & Modeling | 9 Comments

X-Plane 11.02 Beta 1 Is Out

To get this beta you'll need to run the updater and click "Check for New Betas" - we won't ever prompt you to install a beta when you have a final release of X-Plane. Here's the Release Notes. Please file bugs using the Bug Reporter!

11.02 is a small maintenance patch. Our main focuses were:

  • Performance tuning we could do without too much technical risk. (We'll do the more adventurous stuff in 11.10.)
  • Fine tuning the various SDKs.
  • Bug Fixes.

As a small beta, I'm hoping the entire beta period will be less than two weeks.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, News | 59 Comments