X-Plane 11.10 is the first major version release with a lot of code changes and new features. By design, this version has a lot of big changes in it that we’ve held back for weeks or even months. This also means it is more likely to be unstable and buggy, especially for the first few beta releases.
We’ve recently progressed to internal beta testing. Now we should have a public beta sooner rather than later, so I wanted to bring back out some great tips on beta testing that Chris wrote way back in 2012. Nearly all of the info remains as relevant today as it did 5 years ago, and I’ve included his best practice tips below. Read More
X-Plane 11.10 brings a few changes to how airports, the airport gateway, and navdata interact.
Many pilots who try to fly realistic IFR operations with the X-Plane built-in GPS or FMS will have encountered this dreaded window already:
runway 12L not found at Vero Beach Municipal airport
The reason for this is that coded instrument flight procedures (CIFP) come from very reliable sources – Jeppesen or LIDO (depending on whether you get your data updates from Navigraph or Aerosoft), while the runways on X-Plane’s airports come from a community driven, open database: The X-Plane airport gateway.
Unfortunately, the airport gateway community is not always fast when it comes to runway renames or airport expansions, which happen all the time all over the world. The most common reason for a runway rename is a shift in magnetic variation: Runways are named for their cardinal direction relative to magnetic north. While the runway’s orientation with regard to true north is fixed[citation needed], the orientation measured against magnetic north changes over time, as the magnetic pole moves and local magnetic declination changes. Now when the magnetic course of runway 11L changes from 114 to 115 degrees, airports paint new numbers on their runways. 11L-29R becomes 12L-30R. Jeppesen knows about this and changes the runway name in all their data, which ends up in a data update for X-Plane. Meanwhile, the scenery author community over at the airport gateway of course has more exiting things to develop then a runway rename.
To make things worse, runway renames are super annoying in WED. After you renamed the runway from 11L to 12L, you had to go through ALL your flows, ALL your taxiroutes, and ALL your airport signs to change the name EVERYWHERE.
In the past, we have partially solved this problem by running mass renames of runways in the gateway database rather than through WED. If you see a change on an airport made by a user named “WEDbot” (like at this airport) that is usually such a batch-rename.
With X-Plane 11.10 and WED 1.7 there are some big changes that greatly improve the interaction between X-Plane airport data, navdata, WED, and the airport gateway.
Easy runway rename in WED
WED 1.7 has a function that changes all flows, routes and signs for you when you rename a runway end. This makes bringing an airport up-to-date a nearly foolproof operation even for a WED-dummy like me. You don’t need to be a scenery wizard to simply fix an airport anymore.
Silent runway rename in X-Plane
If you have navdata from Aerosoft or Navigraph, and a runway in the X-Plane airport matches a runway coming from the navdata, but the name has changed, X-Plane 11.10 now silently renames the runway at runtime for you. Which means, even if a 11L is painted on the runway, the FMC can load the procedure for 12L and get you there. This only works if the scenery is properly georeferenced and the runway is actually in the right spot – if the scenery was made incorrectly and the runway is not at the right coordinates, this obviously doesn’t work.
Silent threshold fix in X-Plane
Not all scenery authors correctly place displaced thresholds. A bit of confusion exists over when to use the white arrows or the yellow chevrons – and which counts into the runway length and which doesn’t. I teach my student pilots “the only thing you can do on yellow chevrons is crash – anything but crashing on that area is illegal.” Hence this area doesn’t count for runway length. Again, if you work off a properly georeferenced orthophoto, you won’t have any problems. Unfortunately, if you misplace where the (displaced) threshold is, this coordinate problem can feed back into the instrument procedures of this runway. For example, for many non-precision approaches the MAPt of the procedure coincides with the runway threshold, so if those coordinates are off, so will be your missed approach point. With X-Plane 11.10, if a runway in the airport scenery matches a runway coming from your updated navdata, but the threshold is laterally offset from where it should be according to instrument procedure data, X-Plane silently moves the threshold coordinates the GPS/FMS works off to the correct location. This works if the scenery is “good enough” in that the majority of the runway pavement is where it should be, and the thresholds are only off in the direction of the runway. If the whole scenery is ill-referenced, meaning the runway is off other than along its major axis, this obviously doesn’t work.
Silent and not-so-silent feedback
If you have enabled anonymous data collection in X-Plane, whenever your X-Plane silently applies a runway name or runway threshold location fix in the background, it also sends a packet of data to our analytics server, telling us the airport you were approaching and what was up with the runways. Collecting this data from a wide range of X-Plane 11 users will allow us to generate a heatmap, i.e. the most important airports that need the gateway communities’ love. Note that this data is collected only if you are running navdata that is current – we are not collecting reports based on historical data.
Only if both of the above fail, which means the airport has both a problem with its runway numbering and is ALSO poorly georeferenced (runways are in the wrong location geographically) the situation is beyond fix for the new runway logic. Only in this case you will see the dreaded dialog, because the runway simply does not exist in X-Plane, at least not where it should be. In this case, you will be able to submit an automatic report to the gateway website if the problem exists with current navdata. Note that this dialog will come up whether you have enabled data collection or not – but you can still chose to close it without actually posting the report if you don’t want to.
Only this kind of “all is lost” reports are actually visible on the gateway website and the XSG bug database. This allows artists to see the only airports that are actually so outdated that they cannot be fixed automatically. The automatically fixable scenery errors no longer clutter up the gateway airport bugbase.
Any downsides?
The downside to all these changes is that they all actively work to keep the X-Plane default scenery up to speed with the airport changes in the real world. This means that over time, as our global airports follow the real world in terms of runway renames, airport construction, expansions, etc… it will become less useable without up-to-date navdata. That’s the price we have to pay for “as real as it gets”.
Break ALL the scenery!
Poorly georeferenced scenery has a problem beyond affecting the missed approach points of non-precision approaches. It also affects the ability to use the new SBAS (satellite based augmentation system) approaches that are comparable in accuracy to ILS. I always prefer to fly the LPV approach if given the choice. However, the FAS block (final approach segment) comes from the navdata, which means it guides you precisely to where the runway is in the real world. If the X-Plane scenery is poorly referenced, the approach will dutifully fly you into the grass in X-Plane, if this is where the runway would have been in the real world. This is obviously a problem for serious training scenarios. Therefore, X-Plane 11.10 can be started with the commandline option –accurate_runways which will dynamically rewrite the actual scenery in X-Plane after loading an approach, both moving the runway into the correct geo-location and also changing the numbers written on the runway if needed. This obviously only works on default scenery with the procedurally generated runway textures. It will not change custom scenery that uses draped polygons for photorealistic runway textures. Moving the runway into the correct location will obviously also disconnect it from any incorrectly placed taxiways. Also, using this option increases load times for selecting an instrument procedure significantly, since it has to rebuild the airport scenery. So this option is really only there to help you keep limping along with broken scenery, if your operation absolutely requires accurate runways and you can live with some broken taxiways. It is therefore not available as an “official” setting. Do not come to us to complain about the jarring results – make a proper fix in WED instead! The results can be quite disruptive, but at least the approach won’t guide you into the grass:
This LPV approach required the runway to be moved quite dramatically. See the taxiway that was parallel to the runway in the scenery.A closer look at the situation above. This is an extreme example. This airport scenery had the orientation of the runway badly wrong. Note where the threshold was originally placed by the author where the taxiway now ends in the grass.
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://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 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.
