To get it, make sure you have an X-Plane install you can scrap, have a stiff drink, and check “get betas” in the installer.
Release notes are here. I’ll try to post more over the weekend about some of the new stuff, but there’s a lot, and we’ve probably left things off the initial notes. For now, since it’s beta 1, our main concern is “does it work at all?”
We’ve been working on bug fixes like crazy, and over the last week or two we’ve run a small internal beta of 11.10 to try to get the biggest, nastiest bugs out. So far it looks like we’re on schedule to put out a public 11.10 this week.
Besides fixing bugs, there are still a few irons in the fire for 11.10 that might go into the beta after public beta 1:
A bunch of stuff for developers and artists is already done and ‘in the can’ for beta 1:
In preparation for this beta, Jennifer ran off to Las Vegas. We might reasonably disagree on how to interpret that.
This is never okay in a library.txt file:
EXPORT lib/something.obj ../opensceneryx/object.obj
This is a library path that refers to a file outside its own pack by using ../ to go up a directory and hopefully find that OpenSceneryX is installed, at which point it assumes that it knows the internal layout of OpenSceneryX and exports the object.
Do not do this.
This will become a warning as soon as I can write some code.
This will eventually stop working completely, because it’s a terrible idea that I have said multiple times should never be done.
This is a small feature but for plugin developers it may make a huge difference in work-flow.
In the plugin system up to version 2.1 (everything we’ve shipped through X-Plane 11.05) plugins are packed like this:
my_plugin/ my_plugin/64/mac.xpl my_plugin/64/win.xp
This has one problem: every plugin on your install is either named mac.xpl, win.xpl, or lin.xpl.
And as it turns out, pretty much every debugging tool ever assumes that each DLL will have its own unique name because it’d be crazy to do otherwise. The decision to make the file name in the fat plugin structure the OS was a really dumb one by me.
With version 3.0 of the SDK, you can now pack like this:
my_plugin/mac_x64/my_plugin.xpl
and with that format, each plugin’s name makes its DLL unique.
This should fix a bunch of things:
The existing 2.0 format (fat plugins shown above) and 1.0 format (thin plugins, supported only in the global plugins folder) will continue to work indefinitely – they’re still there.
But if you are going to target X-Plane 11.10 and use the new plugin system features, you may want to use the new packaging and save yourself some debugging chaos.
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.)
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.
These both come from third party developers – one I was aware of and one was completely new to me.
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.
As a side tangent, when debugging a plugin, find ways to load X-Plane faster. A few things that can help:
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\LayersEach 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.
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.
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.
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:
(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.