X-Plane 11.20 is, of course, final! Like all good Klingon software, it was not so much released – rather it escaped captivity, leaving a trail of blood in the path of all whom opposed it.
I am aware of two plugin-related issues we are tracking:
Some legacy plugins with widget UIs are missing buttons when the UI is at 150% or 200% scaling. We have a fix for this, but for now you can work around the problem by turning off UI scaling in the graphics settings tab.
Some Mac plugins compiled against libstdc++ crash with the Steam version (but not the non-Steam version).
Philipp and I are still discussing what to do about this second thing, but if your plugin is in this category (so far we’ve seen it with HeadShake and X-Ivap), my suggestion is: compile and link against clang’s libc++ on OS X – it’s the native Mac C++ runtime and the one that’s going to work well in the long term.
We’ll release an 11.21 release candidate either late this week or early next week, once we collect the bug fixes that got away.
Third time’s charm? Maybe? RC3 fixes plugin issues we were seeing in RC2. Thanks to the plugin developers who tested our repaired XPLM DLLs yesterday. We’ll update Steam to RC3 soon if this build isn’t on fire.
X-Plane 11.20r2 has only one bug that we are trying to fix: a bug in the plugin SDK that can cause some plugins to crash when creating and destroying windows.
Tyler and I dug into this and found that the fix was a bit more intrusive than we wanted for this late in an RC.
So: if you are a plugin developer and you are working with the new SDK, either for VR compatibility, to use the new 3.x APIs, or just because you are updating the plugins, and you have time this weekend, please email me and I can send you our new fixed XPLM DLLs.
My hope is to get half a dozen plugin developers to bang on them over the weekend, so that when we cut 11.20r3, it really will be the release.
Edit: RC3 is live – thanks to everyone who helped!
We received a last minute bug report that X-Plane 11.20r2 deletes scenery packs from scenery_pack.ini. This is true! It is also by design, not a bug, the same as X-Plane 10, and not particularly brilliant on my part.
scenery_packs.ini persists the order of your packs (putting newly discovered packs “in front” in alphabetical order upon discovery) and maintains enable-disable status. But it does not retain any other information. The file is totally rewritten on every run and the following otherwise useful stuff tends to get destroyed in the process.
Comments and notes to yourself
Whitespace and formatting
Any scenery packs that can’t be found
Unfortunately this means that if you symlink to an external drive that is unmounted and run X-Plane, your scenery pack order gets lost. This definitely does suck.
In a future version, I can fix this. But we’re not going to mess with it now during RC because it’s totally not changed or broken compared to all past versions of X-Plane since we introduced the scenery_packs.ini file.
For now: you can lock the file as a hack-around to preserve your well-created order while your remote drive is unmounted – when you re-mount and restart, your order isn’t lost. But in this order, new packs aren’t persisted to the file, although they will be used.
If there’s things you want the scenery_packs.ini file to do, commenting on this post would be on-topic. One thing to consider: if we can’t drop missing packs, how do we know a pack was uninstalled? How does the file ever get cleaned?
X-Plane 11.20r2 is up – we’re just killing off the last show-stopping bugs – full notes here. Steam build should be available Real Soon Now™ – it’s already uploaded and just waiting to make we didn’t blow something up.
X-Plane 11.20b5 came out this week – notes here. Beta 5 fixed the rest of our open rendering engine/material bugs, including artifacts on orthophotos. If you are a scenery or aircraft developer, please check your aircraft or scenery against 11.20 beta 5 and make sure there are no rendering changes compared to 11.10. If it looks different than 11.10 in a bad way, we don’t know about it and it’s not going to be fixed if you don’t say something.
Over the last year we’ve been working quite a bit internally to automate testing. We still do a lot of hand-testing (that is, Jennifer flies the sim and then tells us we’re bozos) but we also have extensive infrastructure to script the sim. So we’re looking to automate the process of checking third party scenery for rendering artifacts, so we can catch more rendering bugs more often.
I’ll post once 11.20 is final about how to get your custom scenery into our test. My hope is that with automation, we can catch bugs faster and you (the third party author) can have your add-on tested without having to do the work yourself.
I’m OOTO next week but if things go well, we’ll have a release candidate when I get back.
After much bug fixing, X-Plane 11.20 beta 4 is out – here are the fixes. This beta fixes Linux performance, a few material rendering bugs for custom aircraft, and a bunch of X-Plane SDK bugs for VR.
And…we have docs on the vrconfig.txt file format. The VR config file is used to add VR-specific data to an aircraft, including:
Hot spots for seats (E.g. where does the pilot sit).
Extra data for manipulators.
Parameters for the yoke in VR.
Please do not ship your add-ons based on 11.20 VR tech – wait for us to go final. All file formats are subject to change during beta!
We are reaching the end of beta, for both WED and X-Plane. We’ll see, based on incoming bugs, whether we need a beta 5 before RC; hopefully WED 1.7.0r3 is a keeper.
We’ve been working on 11.20 beta 4 for a while now – the goal for beta 4 is to fix all of the SDK/authoring bugs and have docs for the new VR file formats. We’re making good progress; beta 4 should be this week, barring an unforeseen bugtastrophy. (Linux users: perf should be fixed with beta 4.)
We received a number of bug reports that beta 3 was showing large numbers of _vrconfig errors with third party aircraft. So this seems like a good time to re-iterate our policy on file format stability and betas.
Don’t ever ship an add-on that uses an undocumented file format. You can’t guess what the fine print is from example aircraft.
File formats are subject to change during beta, and are not stable until we go final. Don’t ship your add-ons against beta file formats.
In our case, the _vrconfig.txt file format changed in beta 3 and will change again in beta 4; as Chris wrote docs, he found issues that he is fixing.
Our priority during beta is not stability of your add-on, it is getting the file format right, so we’re not stuck with a buggy file format for the rest of time.
Once we go final, we’ll put compatibility code in to support the final version shipped in X-Plane when needed.
Similar logic applies to the SDK – it’s fantastic that people are using the latest SDK to test their plugins in VR, but don’t hit the “ship it” button until we’re final – it is always possible that the SDK will change in a way that breaks compatibility during the beta.
X-Plane 11 has had several fantastic updates to the library of lego-brick airport objects that ship with X-Plane. We’ve had new European-style objects, elements for small airports, and the terminal and jetway kits let you build really great looking airports that fit the exact shape of the real-world airport you are modeling.
In that context, I’m pleased to show you a sneak preview of the next set of lego-brick objects for gateway airport authors.
New Static Airplanes
New Static Helicopters
Emergency Vehicles
Luggage Tugs
Jet Blast Screens
You can download a preview if the new lego bricks here.
