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 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:
You’ll be able to start X-Plane via X-code to debug your plugin without all hell breaking loose.
Back traces on Windows debugging tools should make the plugin executing clear even without symbols.
Any kind of memory map dump (including those in Apple crash reports) will unambiguously show what plugin code is loaded into what memory address.
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.
XPlane2Blender’s new version number system will allow us to debug .blend and .obj file even faster. It should also make making updates to the data model easier to implement.
Every exported .obj file’s footer contains information about the addon version, when it was compiled, and why. For example: 3.4.0-beta.5+1.20170922151901
A break down of the components
3.4.0: The traditional Blend addon number
beta: The type of build cycle we’re in. Other choices you may see are dev (a developer build), alpha, rc (for full release)
5: the build type version we’re on. Since this is beta 5, the build type version is 5.
The elements after the + are generally less meaningful to the average user
1: The version of the data model (the properties and settings for XPlane2Blender, used for comparing changes
20170922151901: The “build number” date this source code was packaged and released in the form of YYYYMMDDHHMMSS in UTC.
Communication
The build version number is partially shown (elements after the + are hidden) in the scene settings under Composite Normal-Textures, potentially along with warnings about the stability of the build you are using.
Examples
When starting this version of the beta, you will see this:
A future stable version of 3.4.0 for the general public will show this:
Notice the green check mark and lack of any warnings.
In a future pre-alpha cycle for 3.4.1, two types of people will see the following:
A developer writing and testing unreleased code
Someone who didn’t head the warning against using such code, or get scared off by the nuclear symbol and extra warning about a lack of a build number
It is the worst case scenario for stability and traceability, hence the nuclear symbol.
Why the extra warning about a lack of a build number?
A lack of a build number indicates that you do not have a good dialog (e-mail, chat, this release page, or other channels) with a knowledgeable and attentive developer. This means your work is more likely to be run through a bad version of the code and damaged, or your bugs will be harder to diagnose and repair.
In this case, despite the code appearing to come from a stable era of the code near a release, there is potential for something to be wrong and have very poor ways of tracing what it could be – hence the lack of green check mark and big red warning symbol.
If you see some new pre-alpha feature you’d like to try, just ask us about it first. Going forward, we want to start with a dialog about potential dangers, testing, and intentions of an incomplete feature rather than an autopsy later on. Don’t be scared, we always love hearing from users before there is a problem, not after!
Build Version History
Also, all .blend files will be keeping a log of every different version of XPlane2Blender that they are opened and saved with. This is automatic and needs no involvement from the user. Those who are curious can look in the Plugin Development Tools section at the bottom of the scene settings and see the history of their file.
Note: This does not record any history data about Blender versions, other addon versions used, timestamps opened or saved, or changes made to it (including XPlane2Blender settings changes). It is purely useful as a debugging tool, and is not fool proof.
This .blend file started as a legacy 3.4.0 pre-beta.5 file, and was then with a copy of 3.4.0-beta.5, with no build number. Then it was used with 3.3.12, then finally, used with a build of 3.4.0-beta.5 created on 09/18/2017 at 01:27:30am.
One could use this information to guess what transformations the data could possibly have gone through along each step of its journey.
With 11.10 there is a new way aircraft only shadows are done, as well as how aircraft icons are generated. The big change is how we calculate the volume of the aircraft which up until now was based on all OBJ files that the aircraft ships with, including things like ground- and fuel trucks, stairs etc. The reason this is undesirable is because the greater the volume of the aircraft, the worse its realtime shadow quality will be because we use the volume of the aircraft to calculate our shadow map area. The bigger that area, the worse the shadow quality and the more pixelated it will look like. In an ideal world, the aircraft volume tightly hugs around the actual aircraft and we get the best shadow quality possible. With 11.10, hopefully this ideal world is finally here!
Why and how we failed before
Before 11.10 the aircraft volume was based on the volume of, well, the aircraft. However, this includes things such as the aforementioned ground trucks, fuel trucks and what have you, that artificially blow up the volume calculation. The problem is, all these objects are technically part of the aircraft (eg. we move them around with the aircraft), but they are for the most part invisible and most people wouldn’t actually consider them to be part of the aircraft proper.
In 11.05 we added a change to also consider the physical volume which kind of has the right size for the plane but doesn’t include OBJs. It is based on the physical size of the plane only, which sounds like it’s the right thing. However, as it turns out, this volume breaks badly for things such as helicopters because the rotor of some third party helicopters are attached OBJs and won’t be considered part of the physical volume of the helicopter.
At this point I should probably also quickly note what happens if the shadow volume is too small: Everything that gets clipped by the shadow volume will cast a shadow into infinity and beyond due to the way the shadow mapping works. This is especially bad for the helicopters that now have very quickly rotating bits that are constantly clipped by the shadow volume resulting in shadows flickering all over the place.
In short: What we want is a shadow volume that is as tight as possible around the aircraft for shadow quality, but not too tight because that also leads to problems.
What’s new in 11.10
In 11.10 the algorithm to compute the shadow volume has been completely changed. Instead of trying to jiggle around with the physical volume and the volume of all OBJs together and then coming up with a sane value, X-Plane now looks at what is actually being rendered. We start out with the physical bounding volume as before, but then we look at what is actually rendered! For that, we go through every OBJ that is marked as casting shadows and run the OBJ engine as if we were to render the whole thing. So OBJ animations as well as kill datarefs etc are considered. This happens during the first frame, so everything is set up the way it would be during normal rendering. Everything that is visible will be marked as such and the shadow volume will be expanded to include this OBJ.
The result is a volume with a tight fit around what is actually visible and therefore considered “aircraft”. Everything else is not included in the shadow volume and therefore stops casting shadows altogether. Of course, this is only in aircraft only shadow mode and is not used when scenery shadows are on. In that case, everything is handled like it was before and everything that is supposed to cast shadows does cast shadows. So, if you see missing shadows in aircraft only shadow mode, this is probably due to this change.
To visualize the differences, here are 4 screenshots showing the quality difference as well as the new shadow volume:
11.10
11.05
11.10
11.05
One thing that should be noted though is that going forwards these kinds of extra OBJs should really be done via the new drawing API in the 3.0 SDK! This allows us to very accurately determine the size of the aircraft but it also means that culling will become more accurate. The old method will of course continue to work, but it’s not the best or most efficient way to approach ground vehicles and other ground clutter.
Aircraft icons
The calculated volume for the whole aircraft with attached OBJs was also used for the aircraft icon generation. This led to some weird cases where the camera was positioned in such way that the aircraft was incredibly tiny due to the fact that we tried to get “everything” in at once. So far the recommendation was for authors to create a version of their aircraft without all the extra OBJs attached, but now that we have an adequate measure of the aircraft volume this is fixed as well! Aircraft icons should be correctly generated now with the camera positioned to capture the plane at the right distance.
There is one more fix for aircraft icons: Some authors created aircraft that did some clever culling based on where the pilots head is and then using the kill dataref to prevent parts of the aircraft from being rendered. Reading the view dataref now correctly reports the camera as being an external camera so that those custom culling solutions work with the aircraft icon generator. If your aircraft still doesn’t generate proper icons after 11.10, please file a bug report and let us know!
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:
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.)
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.
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.
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:/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 1×1 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 1×1 pixel png as the “cockpit/radios/GPS FMS/Garmin_430_2d.png” resource of your plane.
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.
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.
