Plugin Compatibility and New XPLM 3.0 Features

Tyler posted about some of the new features coming to the X-Plane SDK version 3.0 API (available with 11.10 once we find the last bug and move it somewhere else). Here's how compatibility works for the windowing system.

First, since the 2.0 SDK, XPLMCreateWindowEx has taken all of its arguments in a structure, a XPLMCreateWindow_t. That structure, in turn has a structSize variable that is meant to be initialized like this:

XPLMCreateWindow_t my_win = { 0 };
my_win.structSize = sizeof(my_win);
my_win.froblinator = xplmFull_Of_Eels; // etc.
XPLMCreateWindowEx(&my_win);

Now when we revise the SDK, the size of the XPLMCreateWindow_t structure grows when you #define XPLM300. This results in new plugins compiled with the new SDK sending in a large struct (with more callbacks) and older plugins compiled against the old SDK sending in a small struct.

This is how the SDK "knows" what SDK you are using and provides new behavior to new plugins but provides compatible behavior to existing plugins, compiled years ago.

(This technique isn't in any way new or unique to the X-Plane SDK - you can tell by the coding conventions that it is cough, cough, borrowed from the Win32 SDK.)


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Plugins | Leave a comment

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.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft | 15 Comments

Three lesser known aircraft features for 11.10

These smaller features are likely to be overshadowed by the release of the G1000 for default aircraft in 11.10, so I decided to dedicate a blog post to promote the articles I've written  - you can find them among all the guides for aircraft developers: http://developer.x-plane.com/docs/aircraft/

Electric and remote gyro systems

Back in April, I flew a Mooney M20J with a KCS55A HSI in it, and realised that it was impossible to model in X-Plane correctly, so I got to work. See the manual for an explanation of this popular HSI/remote gyro system.

I've written a usage guide on the new datarefs and commands that I added, along with some more detailed explanation of all the different gyro systems X-Plane simulates, in this guide for aircraft developers. I also talked about the systems at length in a Youtube live stream earlier this year.

Separate GPSS autopilot mode

This is a feature that many add-on aircraft already simulate to some degree, but by means of more or less reliable plugin trickery. The X-Plane 11 default 737 and 747 are no exception. With X-Plane 11.10, a separate GPS steering mode for the autopilot becomes a standard feature.
The new datarefs and commands are explained in detail here.

Screen-only popup instrument windows

Several people who build home-cockpit setups have asked about removing the bezels from the popup displays, so they can have only the screen of a GNS430/530, FMS or G1000 instrument to put on an external monitor, with a hardware bezel around it. While this can already be achieved through some clever hacking in the Miscellaneous.prf file, we now offer a more straightforward way to do this: The popup and pop-out windows now get their bezel graphics from the library system, so you can override the bezel graphics. How to override the bezel with nothing, if your bezel is made of hardware? Simply supply a 1x1 pixel blank .png as a bezel graphic, and X-Plane will know that you really want no bezel at all. In the case of a bezel-less 430, you'd put a 1x1 pixel png as the "cockpit/radios/GPS FMS/Garmin_430_2d.png" resource of your plane.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft, Aircraft & Modeling, Cockpits, Panels, Uncategorized | 29 Comments

Some Bugs

Some bugs are so beautiful it hurts to fix them.  This is an X-Plane AI Aircraft...

...flying like Austin drives. Fixed for 11.10, sadly.

EDIT: The video has post-processing effects added for drama (Shallow DOF and color grading). X-Plane does not natively ship with dramatic opera music.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Air Traffic Control, Blooper Reel, Development | 74 Comments

Two “Gotchas” Developing Plugins

These both come from third party developers - one I was aware of and one was completely new to me.

The Debug Heap Is Slow

Veteran Windows C++ developers know this, but if you don't spend a lot of time with MSVC, this might be new.

The default configuration of MSVC is to force use of the debug heap when the debugger is attached; this applies even to release builds of binaries that aren't yours.

What this means is: if you do nothing else but start your plugin "inside" X-Plane, X-Plane will use Microsoft's debug heap.

We avoid doing this internally because it is really, really, really slow. The debug heap provides some great tracking for finding memory problems, but the cost is really, really slow load time.

The fix is simple: add _NO_DEBUG_HEAP=1 to the environment variables for your debugger. You can do this in the control panel as shown in the linked article, or you can add it to MSVC's debugger properties.

Other Things To Go Fast

As a side tangent, when debugging a plugin, find ways to load X-Plane faster. A few things that can help:

  • Turn off AI aircraft.
  • Pick a simple aircraft to fly (e.g. not the 747).
  • Go somewhere without scenery (or without much scenery, e.g. PMDY).
  • If you have to have scenery, turn 3-d all the way off.

My Plugin Won't Reload

We receive periodic bug reports that plugins won't reload on Windows. This is miserable for you as a third party developer - it means rebooting the sim instead of just reloading your plugin. But why does it happen?

I thought we had a bug, but a third party developer found this:

I did searched the registry for the names I've used for X-Plane 11 folder and found this items at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windws NT\CurrentVersion\AppCompatFlags\Layers

Each name used was included there with "$IgnoreFreeLibrary<win.xpl>"
value, after removing them and restarting X-Plane I got able to compile the plugin using the names again.

I have not found any official Microsoft documentation on this, just a lot of ranting from really annoyed programmers who want to know why the hell Microsoft would do this. If anyone has better Google-Fu than me and can find official docs, please do share. So what follows is my wild speculation of what's going on.

In some old version of Windows, FreeLibrary probably didn't actually (or immediately) free a DLL under certain circumstances. Application developers then wrote buggy apps that relied on this behavior, e.g. they freed a library while it was in use and their app didn't crash.

Microsoft updated Windows and made FreeLibrary do what it says on the label, always, and old buggy apps started crashing left and right.

Microsoft, being Microsoft, did not say "you app developers are idiots, why don't you go rewrite your buggy apps". Instead, they added a feature to the App Compatibility Wizard that watches your app and, if it crashes after a DLL was unloaded and the moon is the right shade of Rondele, it adds a registry key marking this library as "never to be unloaded, even if this app says so".

From that point on, the app doesn't crash because the old semantics of FreeLibrary ("ha ha ha, you don't mean that do you") are restored in that one case.

The above is entirely made up - it's my mental model for what might have happened, unless Raymond Chen someday gives us some back story.

Still, you can see what has gone wrong here - Windows decided that for compatibility reasons, plugins should not actually be unloaded, and since all of your DLLs are named win.xpl, this one plugin crash has caused plugins to never be unloaded. Thus the plugin unload/reload never releases the DLL and you can't swap in new code.

Nuke the registry key and you're back in business, at least until you crash again.

 


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Plugins | 9 Comments

X-Plane 11.05 is Final

X-Plane 11.05 release candidate Two is now the official version of X-Plane 11. You'll be prompted to auto-update.

11.05's purpose in life was to release new gateway airports. We will do another release of gateway airports for X-Plane 11.10, which we are working on now.

When Will X-Plane 11.10 Be Released?

I don't know! I don't have a crystal ball. How can it be that I am tasked with making the final release-not-release decision and I don't know when the first beta will be released?

X-Plane 11.10 is limited by bugs, not a particular release date. In particular, we intend to ship X-Plane 11.10 with our latest rendering code, and our latest rendering code currently has a few serious bugs. So it will be released when we fix these bugs, but I can't predict how long it will take to fix them.

Some of our releases are date driven, and we remove functionality to hit the date. Other releases are feature driven, and we release when the bugs are fixed. 11.10 is in that later category.

We'll post a lot more details on 11.10 once we get into beta; 11.10 is going to be a long beta, to give third parties time to help us flush out compatibility bugs. We've changed a lot of code.

11.10 will (as planned) ship without VR support, but will contain all of the rendering engine changes necessary to make VR work. We are working on VR in parallel, and can hopefully public beta VR as soon as 11.10 is out of beta.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News | 45 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.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Plugins | 27 Comments

XPlane2Blender v3.4.0-beta.4 arrives

Download here:

https://github.com/der-On/XPlane2Blender/releases/tag/v3.4.0-beta.4

Change Log

Bug Fixes

  • #294 - A case where autodetect off was not fully trusting the author for Aircraft exports
  • An uncaught spelling mistake __upgradeLocRot vs __updateLocRot. The fix for the updater altering the animation types was written for object's dataref animations and bone's dataref animation troubles. However, with this spelling mistake and Blender's uncanny ability to eat exceptions from addons, it wasn't realized until later that bone's weren't also getting updated. Fortunately, the updater can be run-again without fear of messing something else up.

At the bottom of the Scene Settings, check "Plugin Development Tools". Use the Re-run Updater tool at the bottom: Put in 3.3.9 in Fake Version, and click the button. You should see your bone values corrected, as long as you successfully reverted any bad changes from v3.4.0-beta.1. Please e-mail me if you have problems!

Improvements

  • Some spelling and capitalization in the UI. Great care has been taken to ensure that none of the actual value or order of the addon properties has changed!



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

11.05 Release Candidate 2 and Friends

11.05r2 is now available - if you have 11.05r1, you'll be notified to auto-update. We fixed the broken SIDs/STARs at KMCO, removed a few custom Aerosoft lego brick airports to reveal the gateway one, and we have some updates to KLAS from Julian.

This should come out on Steam in a day or two if no one finds something on fire and hopefully be final this week.

We're working full time to get 11.10 ready for beta, hopefully very shortly after 11.05r2 is final.

Update: Steam users can get 11.05r2 as well by opting into betas.


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

Talking to Plugins

We're continuing to integrate X-Plane 11.10 (with mixed success!); we'll get more info on 11.10 posted once we're in beta.  11.05r2 will come out as soon as I get my hard drive fully restored - from the looks of the comments this should be Real Soon Now™.

This post is for plugin developers - if you don't write plugins, I suggest cat pictures instead.

For as long as there has been OBJ animation, X-Plane has called the XLMGetDataXXX APIs from inside the OBJ engine as drawing is taking place. These calls eventually show up in your plugin in your dataref read callback. You might even see X-Plane code on the stack if you put a break-point in your read accessors.

This design has two major draw-backs:

  1. It's bad for multi-core. Since the plugin API is single-threaded, operations requiring us to know the animation state of an object (drawing, collision testing, etc.) require us to be on the main thread. So this doesn't scale well.
  2. It's inefficient. We might have to draw your aircraft several times - one or more times for reflections, one or more time for cascading shadow generation, and once to draw (or more for multi-monitor). The work to fetch those datarefs is done multiple times, even though we don't want different answers between drawing passes.

(In fact, it's worse than that - if you have the same dataref used in multiple animations, we just request the dataref over and over...not real clever.)

X-Plane 11.10 changes this for the first time: we are starting to collect the entire set of datarefs we need to draw a model in a single burst. We can then save these dataref results and reuse them.

This is just the beginning of a series of changes to make the rendering engine multicore-friendly. Hopefully it won't affect any add-ons* - this should have no effect unless you are doing highly illegal things with the SDK.

I am hoping we'll see some performance benefit by not spending as much time in plugin code, but I don't have numbers yet.

* Plugins that read the object-draw-location datarefs to do multiplex their datarefs on multiple models should still work; we set those object-location datarefs before we collect all of the datarefs for your model.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development | 19 Comments