As we move forward with the beta, we’ll write up some posts on X-Plane 11.10’s the new features – there are a lot of them, to the point where I’ve lost track of what’s actually in the release. Right now we’re in the “does it work” phase, trying to get a beta that works for everyone without crashing. (Beta 1 worked fine for everyone in the company, but often our internal machines are very similar to each other, so early betas catch things we missed.)
So what follows is a big pile of nerdy stuff…I’m going to add random images in to make the post less boring. So picture is not related.
Where Do The Bugs Go
Planet Ferrari
When you file a bug with our bug report form, it goes to a shared email in-box that someone triages – usually it’s Jennifer, but sometimes it’s me or Philipp. The person triaging the bug will then forward it to our internal bug tracking system (that’s where those XPD-123 numbers come from) or possibly forward it to tech support – we do get a lot of “my sim is broken, help!” in the bug reporter.
This is why I always jump up and down and go “file a bug!”: everything in the bug reporter gets looked at, and everything that is then filed is permanently tracked. At the end of 11.10 we can check the bug list and see what hasn’t been fixed. Like all software, not all bugs will be fixed by the end of 11.10, but if the bug is tracked, this avoids us losing the bug.
Here are some ways to report a bug that are not tracked and are extremely likely to get lost:
Posting in the blog comments section. We do not ‘scrape’ the blog for bug reports. If you write a blog comment and do nothing else, your bug will not be fixed.
“Reporting” the bug on a public forum (x-plane.org, reddit, etc.). We don’t scrape those either, so it’s quite possible no one will see it.
Emailing an engineer at Laminar Research directly.
Night Vision Deserves a Quiet Night
The problem with direct email is that it doesn’t go through the tracking system, you might not get the right engineer, and again, you’re bypassing the mechanisms we have in place to not lose things. If you email someone organized and responsible like Tyler, he might file the bug for you. If you email someone like me, whose in-box looks like a grenade went off, there’s a very good chance I lose your report.
Jennifer tries really hard to list every item that is fixed in each beta, so that you can tell when your issue is fixed and it’s worth re-testing/re-reporting.
This system is far from perfect, and the number one request we get which is reasonable is better linkage between the internal tracking and the user reporting. I sympathize because we have the same problem of “it’s a black box” with the technology vendors we depend on (Apple, Microsoft, Intel, AMD, NVidia).
Changing How We Build
737 With Canards
With X-Plane 11.10 we moved to cmake for our build system. Previously we would maintain separate project files for all three operating systems. That’s about 3x the amount of work it should be, so for 11.10, Sidney and Jörg moved us to cmake, which lets us manage X-Plane as a project once.
The down-side is that there have been a number of serious one-time bugs due to projection configuration problems, since using cmake meant rewriting all of the configuration info for building X-Plane. This is what caused the Linux bug in beta 1 that we required libc++ (fixed during 11.00’s beta process, it popped back up when we replaced makefiles) as well as a number of other random bugs we fixed before public beta started.
In the long term cmake is a win – having gone through the pain of the migration, it’s just quicker for us to administer X-Plane’s project files, which means more coding and less fighting with X-Code, MSVC, etc.
More Robots
The Sky Shader is Out Of This World
In the last few months we’ve automated our build and our packaging process, as well as the amount of testing done automatically by the build system. Hopefully this will turn into bugs being caught earlier, and it makes it easier to cut new betas – getting quick betas out to fix crash bugs wasn’t time consuming. I expect the beta count to be higher for 11.10 than in the past due to the lower cost of recutting the build.
(If I had to cut five betas in a week for 11.05 I’d be pretty cranky at everyone – five betas in a week is totally doable now.)
Graphics Cards That Remember
You Put Your Map In My Cessna
Before X-Plane 11.10, X-Plane would set up shading for a given material by telling the graphics card about every aspect of the material. Over and over. Every time the material was used. For every single frame. For every single view in the frame.
X-Plane 11.10 now stores parts of the materials in VRAM, so they can be referred to as needed. This is part of our restructuring of the rendering engine for VR, Metal and Vulkan.
Monkey See, Monkey Do Silly Things With Substance Painter
This was also the cause of the “invalid UBO” errors in beta 1 – now that we are saving materials and not just reiterating them per frame, we have to get the book keeping right. Sidney set the sim up to crash if the book keeping is done wrong. (This is a good thing – the sim is going to crash anyways if the book keeping is wrong — at least this way the auto-report explains exactly what happened, rather than us having to autopsy the resulting carnage and squint to find the root cause.)
AMD Users: this code is not working on AMD cards right now, which means you aren’t seeing some performance improvements. We’re working this week to see if we can get this going on AMD cards too – stay tuned.
I just cut a quick new beta build of X-Plane 10.11 – Jörg fixed the Linux crash. The crash was a problem with the plugin .so’s and we don’t even know how the bug happened, but it’s fixed now.
Linux users: since the crash is at startup, you won’t be prompted to auto update (because X-Plane crashes before the auto-update check can run). So to fix your beta installation, re-run our installer and pick “update x-plane” with the beta box checked. You’ll get beta 3 and be back in business.
We’ll fix more bugs next week, and the rate of betas may slow down, but we’ll try to patch crashes as quick as we can.
If you have 11.10 beta 1, you’ll be auto-notified to update. (If you’re locked out, e.g. for users on Linux who didn’t have libc++, use the installer and check “Get Betas”). See the release notes for bugs fixed in this beta.
Thanks to everyone who reported bugs! If your bug is not yet fixed, don’t panic – we cut b2 quick to fix the pile of “OGL_ubo_is_valid(s_environment_ubo)” crashes. If you have one of these in b2 please re-report it (and auto-report it!)
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:
Sidney and I have one more set of performance optimizations that are a “maybe” for 11.10 – we’ll try them and if they blow up the beta, they can wait for 11.20.
Jörg has fixed a lot of weapon-related issues – you can actually author fighter planes now – but weapon cam is still inoperative and probably will be in beta 1.
We are working on VR in parallel to 11.10, and we may be able to release some authoring interfaces for aircraft in 11.10 to get aircraft developers a head start.
A bunch of stuff for developers and artists is already done and ‘in the can’ for beta 1:
The new plugin API 3.0 will be fully available in beta 1.
The G1000 will be available in beta 1, and the G1000-based Cessna is included in the install.
New art for airport authors is in place.
In preparation for this beta, Jennifer ran off to Las Vegas. We might reasonably disagree on how to interpret that.
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.
