One of the most well known errors you will encounter in X-Plane is the infamous device loss error. But it’s also one of the least well understood errors and one of the hardest to debug, so in this blog post I want to talk about what device losses are, what we have done to fix them and what you can do to help us investigate these issues. Let’s actually start with the latter because if there is one takeaway from this blog post for anyone, it’s the following:
In case of device loss
If you encounter a reliable device loss error, please run X-Plane with --aftermath in the command line options, or run X-Plane via the X-Plane_aftermath.bat script from the Support folder inside of your root X-Plane folder. This flag currently works with both Nvidia, AMD and Intel hardware, but it will come with a bit of a performance hit. It’s best used in cases where you already know you are going to run into a device loss and want to provide additional diagnostics. I would not recommend just running with this flag, in particular because it does not work around device losses in any way – It just gathers additional data to make device loss debugging easier. When running with Aftermath, next time you encounter a device loss, X-Plane will no longer call it that but instead say “Encountered a GPU crash!”. Please submit those crash reports! If you see this message it means that X-Plane was able to gather diagnostic data that can help identify what happened.
What is a device loss anyways?
Everyone knows that applications can crash. The human species is incapable of writing bug free code and some of these bugs lead to crashes, while others just result in broken logic ranging from mildly entertaining to downright annoyingly broken. But crashes are definitely the worst kind of bug: If you have invested 7 hours into a flight and then suddenly X-Plane crashes, it’s probably one of the worst experiences in flight simming. I know it has put me off from virtual flying for weeks in the past. Luckily, when applications crash, it’s possible to capture the current state of execution and everything that lead up to it. As programmers, we get to see the callstack which tells us not only in which function we are currently in and where, but also what function has called it and in turn which has called that function and so on. We can also see what thread executed it, what the other threads were up to and even the state of the CPUs internal registers that hold part of the current program state. While this isn’t always enough to create a fix, it points in a very specific direction and lets us investigate the code and, together with the log, piece together what happened. Essentially, when you submit a crash report, you send us the black box of your flight. It contains forensic information that can be analyzed to figure out what happened, but we don’t look as cool as NTSB investigators.
Device losses in reality are just crashes as well, but crashes on the GPU. GPUs these days, and really since a long time, are almost fully programmable and just execute arbitrary code. Programs that execute on a GPU are called shaders, a leftover from the olden days when they could exclusively be used to shade vertices. But these days, shaders are just tiny programs that execute on potentially tens of thousands of GPU cores. Shaders are responsible for basically everything that X-Plane puts up on the screen, from mundane tasks like transforming vertex data into screen space, calculating the colour of every single pixel all the way to culling tens of thousands of trees per frame. X-Plane makes use of a lot of shaders because GPUs are incredibly flexible and a lot of workloads lend themselves really well to their highly parallel nature. Counting shaders is surprisingly hard, X-Plane bundles shaders into what we call “modules” which contain variants of similar shaders. But doing a count of just modules, X-Plane 11 shipped with 29, while X-Plane 12.1.3 had 88 modules and 12.2b4 ships with 91. Each shader module contains between a handful to thousands of distinct shader variants, so the real runtime count of compiled shader programs is much higher, somewhere in the mid to high 5 digit range. Quantity is of course not a measure of quality, but X-Plane 12 as well as any modern game wouldn’t be possible without the ability to flexibly run millions of shader invocations every single frame.
Just fix the crashes then
While shaders are no doubt one of the greatest additions to computer graphics, they come at a cost: They are incredibly hard, near impossible, to debug properly. On the CPU side you can attach debuggers to your code and then step through the code as it executes while seeing the result of each operation. On the GPU that is not a possibility, you can’t inspect the state of a running shader, only the results of the execution after the fact. And if nothing shows up on screen, then good luck trying to figure out where your triangles went. And if it crashes, you are even more toast because now you only got broken pieces to look at left. There are tools to make this a bit easier and it definitely isn’t as bad as it used to be, which is a big reason why it’s possible to put a lot of shaders into the field now: The tooling around this is has gotten a lot better. But for crashes, the GPU once again turns into a terrible blackbox.
The first hurdle is that the CPU and GPU run asynchronous from each other. The CPU encodes operations for the GPU into a command buffer that is then submitted to the GPU for execution, so right there you already have a source of latency. In practice, the CPU is usually at least a frame ahead of the GPU in terms of what it is computing. Detecting a crash also involves latency, often the OS/driver has to recover the GPU from its current state and put everything back together. Since the GPU is responsible for getting anything onto the screen, the OS and driver are much more interested in getting you back into a state where you can interact with your computer. But eventually, X-Plane will catch up to the fact that the GPU crashed, because at some point a call into Vulkan will produce the infamous error code VK_ERROR_DEVICE_LOST. This is why it will often feel like your computer is glitching out prior to a device loss, everything stops working for a second, the OS and driver recover the GPU, your windows and displays might flicker around for a second and only then will X-Plane go “yeah by the way, stuffs broken, yo”.
This huge latency between cause and effect is one of the big issues with device loss debugging. By the time the CPU side of X-Plane realizes the GPU is dead, it’s too late to gather data anymore: Something we did god knows how long ago crashed and that’s all the information we have. This is also why the log file tends to just not be very useful for device loss triage. This is especially bad when the device loss is hard to reproduce and happens only once every blue moon. My favourite kind of device loss is the one where you can get X-Plane crash really fast and reliable, in those cases it’s possible to start toggling things on and off and compare what happens to zero in on what is the actual cause. I have spent many a day having X-Plane take down my window manager over and over again.
What’s being done about device losses then?
Over the years we’ve fixed a bunch of device losses. 12.06 was probably the biggest release here, cutting device losses by about 75%. 12.1.0 also reduced device losses by a large fraction by working around a bug in the Nvidia driver. But of course new code gets written and new code can always be buggy. Way back in 11.50 we also added support for Aftermath, which is a library from Nvidia that helps gather crash dump data off of the GPU. In 12.2, I have massively reworked Aftermath support and also added support for AMD GPUs. While AMD does not actually use Nvidia’s Aftermath library, for simplicity sake the same command line option is re-used and my hope is to also add support for this for Intel GPUs in the future Edit: It turns out, Intel supports the AMD extension used for this, so Intel GPUs are supported as well.
With 12.2 and Aftermath enabled, X-Plane now injects per draw/dispatch checkpoints into the command stream. In the event of a device loss, these can then be analyzed to recover the GPUs program state. Because it is very fine grained, this data is incredibly valuable and has actually helped fix two device losses already. The downside is that, because it is so fine grained, it also comes with some overhead. After all for every draw or dispatch command, X-Plane has to stash away some data. But the goal was to keep this as lightweight as possible, the current implementation stores just a couple of bytes of data and defers resolving all of it until after a device loss. Under the hood, this is implemented with Aftermath on Nvidia and with buffer markers on AMD, plus logic inside of X-Plane for the post mortem resolving of data.
And now it’s your turn. Got an annoying device loss? Run with Aftermath, submit your crash reports and hopefully in an update coming to your install soon, that device loss is gone. And maybe by this time next year, I can sip Martinis on a tropical island because my work is finally done.
Misconceptions
One thing I want to make clear though, device losses and running out of VRAM are two entirely different issues. There is a persistent rumour that low VRAM can cause device losses, but this is not the case. The other thing I also frequently see is the advice to uninstall scenery or plugins. Scenery and/or plugins don’t get access to X-Plane’s Vulkan command stream so they can only very indirectly cause device losses. For example, it’s possible that art controls modified by plugins can cause device losses by enabling shader paths that are not normally taken and thus aren’t fully tested. But in general, it feels like there are a lot of snake oil fixes out there, so please be wary. Neither the log nor the alert box have enough information to triage a device loss to even remotely claim that X is the cause of it. That being said, it never hurts to do some simple A/B testing with things disabled, although this might just mask the problem instead of actually resolving it. A/B testing is particularly useful in the case of a repeatable device loss because you can get a much stronger signal from that test, so you can pass that information along with your bug report and make reproducing the issue much easier for us. For random device losses however it’s near impossible to get a clear signal from such A/B tests.
Last week Marco and I were on a live stream and had a chance to talk about some of the upcoming developments we’re working on; next month Marco will be full time with us, but for now here’s a few notes on things making progress in the lab. I’m sure publicly discussing them on Friday the 13th will have no unexpected consequences. (Knocks on wooden desk repeatedly.)
We should hopefully have a release candidate for 12.1.2 next week – this week the team was fixing crash bugs, and we’re down to trying to finishing up stability. Crash rates in the beta look good enough to ship. (Please consider turning on analytics – we don’t collect your personal data but we do record crashed vs non-crashed sim runs – this is how we know whether stability is getting better or worse!)
12.2.0
Dark Cockpits: Art team is evaluating Maya’s exposure fusion work. Generally things look better than the shipping product, but we discovered yesterday that the indirect lighting environment is pretty weird on cloudy days. We’ve been fixing bugs, removing old hacks we no longer need, and I’m optimistic that the update should be both better looking and closer to reality.
We also have some fixes to the PBR material model that may get X-Plane closer to Blender and Substance Painter 2. This is a double-edged sword: we don’t want to change the material model such that everyone has to repaint everything (that would be too much both for our team and for add-on makers) but we do want X-Plane to be as close to WYSIWYG possible to make development faster. Art is evaluating these changes too.
We’re targeting 12.2.0 (a “major free update”) for these changes so we can run a substantial alpha and beta program and give add-on makers time to report bugs.
12.1.X
ATC, Weather: we have two minor releases before 12.2.0 making their way through testing. The first is ATC with SIDs and STARs – as of now it looks like that will ship next, but all releases are subject to change based on bugs.*
The other update is a weather update, and it looks like it may have some substantial features:
New in-cockpit weather radar, with SDK support.
Fixes for real weather bugs, including jumps in pressure altitude (which are driving the autopilots crazy) and some fixes to cloud visuals.
Plugin-controlled weather across multiple locations.
Better weather sync over the internet.
As of now the weather branch also has network sync of trucks and jetways to external visuals. This only affects users using external visuals but for those users, it’s a big feature, and it’s also an important foundational technology for us.
* In the past we have announced “X” is next and if that code was buggy, we’d just delay shipping anything until we fixed it. We’re trying to be more flexible and ship what’s ready first, so good code doesn’t have to wait for unrelated bugs.
X-Plane 12.1.1 is out! This is a quick “bug fix” patch on X-Plane 12.1.0. If you could not load the sim due to problems with XPLM_64.dll, please update using the installer to fix it. Full notes here.
Websocket-To-Me Time
Besides fixing bugs, X-Plane 12.1.1 enables X-Plane’s web API*. Basically we were asked for this so many times at FSExpo that Chris and Daniela put the remaining work on the fast track.
Our plan is to build several services into the web server; the web APIs will not be exact mirrors of the plugin SDK, but will cover enough functionality to build wide range of apps. We have plans for:
Datarefs (shipping now)
Commands (in developement)
Initiializing Flights (in development)
Documentation on the new web APIs can be found here.
Doc-It-To-Me Time
X-Plane alum and fellow X-Plane-10-survivor Tom Kyler is back working on developer documentation for us, and has finished a first release on some of the new X-Plane 12.1.0 features:
Tom has big plans for X-Plane’s documentation; one thing that’s great to see in these docs is really good illustrations based on real sample 3-d models and test projects.
The Devil Is In the Details
A detail texture is a repeating, high detail pattern that adds high-res detail to an otherwise lower resolution texture. Detail textures let us add fine detail at high resolution without using a ton of extra VRAM efficiently. We use detail textures with bits of “gravel” to make the runways look more realistic.
We introduced detail textures over a decade ago in X-Plane 10 to enhance ground detail around airports and in the new (at the time) autogen cities.
What we did not do was give them a good name. At the time we called them “decal” textures. This has turned out to be incredibly confusing, because in every other game engine ever, a high-res texture applied over the entire material (which is what we have) is called a detail, and a decal basically means “sticker that you stick on somewhere”. Detail textures make the ground look more rocky, decals add blood spatter and bullet holes to the walls in your zombie-shooter game.
So moving forward, we are going to try to call detail textures “detail textures” wherever possible, to be consistent with the norms of content creation. Tom and Maya will be updating labels in Blender and doc to be consistent about this.
For X-Plane 12.1.1, Maya has extended the detailing system in two ways:
Detail textures work on OBJs and not just in the scenery system, so aircraft authors can add detail too.
Detail textures can affect the bumpiness of normal maps and not just the color of albedo textures, so detail textures now interact with the lighting model in realistic ways.
* Please note that while the dataref API does use websockets, most of our web APIs are conventional REST requests over HTTP. I did consider “The X-Plane developers never REST..until now” as a section title.
If you’re at FSWeekend, say hey to our peeps there! In the meantime, we’re working to kill off the last 12.1.0 features. A few internal pics* from killing off the last features:
Author-controlled de-icing has had a series of bugs in 12.0.x. For 12.1.0 we’ve gone over it with a fine tooth comb; Alex ran the above tests with our Kingair, which has the unusual case of two overlapping de-icing zones. We’ll have updated docs, Blender exporter support, and builds for authors.
Some tests of real weather. In the first pic, the sky says clear but there’s a distant cloud…because the weather report is local.
Water turbidity is fixed for 12.1.0 and I am finishing documentation for authors. It looks like Oscar’s work on Ortho4XP is on GitHub. Please note that X-Plane 12.1.0 does not improve X-Plane 11 orthophoto water compatibility; v11 packs will only have 2-d water because their meshes are not triangulated properly for 3-d waves.
Based on the progress we done this week, I am hoping we will be able to test these features next week and start a private alpha in our developer lobby.
* Please note: these are internal pics from the developers that I am posting while the marketing team is too far away to object – literally what we were passing around while discussing the features. Don’t panic over FPS; the sim is running a debug build in those real weather pics, for example.
In my previous post I drew an analogy between a scenery system with its file formats and a turtle within its shell. We are limited by DSF, so we are making a new file format for base meshes so we and all add-on developers can expand the scope of our data and make better scenery for X-Plane.
The really big change we are making to base meshes is to go from a vector-centric to a raster-centric format. Let’s break that down and define what that means.
Vectors are fancy computer-graphics talk for lines defined by their mathematical end-points. (Pro tip: if you want to be a graphics expert, you just need the right big words. Try putting the word anisotropic in front of everything, people will think you just came from SIGGRAPH!) DSF started as an entirely-vector format:
All 3-d clutter is defined by lat/lon locations, so we have the vector outline of polygons, autogen blocks, etc.
The base mesh is pre-triangulated, so most base-mesh features are defined by the corners of the triangles forming lines (e.g between land and water).
This isn’t the only thing DSF does – we added raster capabilities and there is e.g. raster sound and season data in X-Plane 12, but DSF is fundamentally about vector data – saying where the edges of things go exactly.
This was great for a while, but now that we have more and more vector data (complex coastlines, complex road grids, complex building footprints) the DSFs are getting too big and slow for X-Plane.
Raster data is any data stored in a 2-d grid. This includes images (which in turn includes orthophotos) but it also includes 2-d height maps (DEMs), and the 2-d raster data we include in DSF now (e.g. sound raster data, season raster data etc). Any time we store numbers that mean something in a 2-d array, we have raster data.
Raster data has several advantages over vectors:
Raster data is what the GPU wants to consume.
Raster data has really good LOD characteristics for close detail with long view distances.
We can put more interesting and dense information into a raster tile without it getting bigger.
Twenty years ago, when I first worked on DSF, computers didn’t have the capacity to use lots of raster data – this was back when 8 MB of VRAM was “a lot”. But now we no longer need to depend on vectors for space savings.
Raster tiles are raster data broken into smaller tiles that get pieced together. Raster tiles have become the standard way to view GIS data – if you’ve used Apple Maps or Google Earth or OpenStreetMap or any of the map layers in WED, you’ve used raster tiles.
Raster tiles have a bunch of advantages too:
They have really great LOD/VRAM usage properties.
They can be loaded incrementally.
They provide an easy way to vary resolution and let authors skip providing data that they don’t need to provide. (E.g. “forest” raster data over the ocean? Just don’t provide any tiles!)
So our plan for the next-generation base mesh is “all raster tiles, all the time” – we’d like to have elevation data, land/water data, vegetation location data, as well as material colors all in raster tile form. This would get us much better LOD/streaming characteristics but also provide a very simple way for custom scenery packs to override specific parts of the mesh at variable resolution with full control.
Raster tiles are not the same thing as orthophotos. A raster tile is any data contained in a 2-d array, not just image data cut into squares (e.g. orthophotos). So while a raster-tile system may make it easier to build orthophoto scenery, it does not mean that the scenery can only be orthophotos.
Thomson and Dellanie posted a preview of what’s coming in X-Plane 12.1 – click over to the news blog to see the pretty pictures. Short story long, it’s a graphics-intensive release, but it’s also a big release, with weather, systems, avionics and ATC updates too. What follows here is a few details for developers.
Private Alpha Builds Soon
As with all past X-plane 12 patches, we are planning to do a private “alpha build” test run with the developer lobby before public beta. We do this both to find out about add-on compatibility and to get the worst bugs fixed with a smaller test group. As of this writing, ATC is at the end of bug fixes, the last graphics changes are being tested, but my weather work is still mid-development.
New Toys for Scenery Developers (and Aircraft Modelers)
This release turned out to have a lot for scenery developers:
Water bathymetry and turbidity should be sorted out, making orthophoto base meshes with 3-d water possible.
The material system now features normal-map decals. These decals add high-frequency ‘texture’ to a surface by perturbing the normals (direction of light bounce) instead of just “painting’ them. This means better looking materials at different lighting angles.
LOAD_CENTER is now usable on OBJs. This means you can set the resolution of an OBJ to be based on distance to the aircraft (just like draped polygons and orthophotos); I think this has the potential to ensure that “land mark” OBJs (models used exactly once) are at their highest resolution when the user is near them without hurting VRAM in general.
If it passes test (crosses fingers), particle systems can be used directly from DSF objects.
The entire DECAL system (existing and new normal map decals) are also usable in OBJs for aircraft as well, and the particle system has received some upgrades that can be used everywhere.
One warning: the old “smoke puff” directive for OBJs from X-Plane 8 is now inoperative; with 12.1.0 we finally removed the old particle system completely. I suggest using the new particle system as it will give you real control over what kind of smoke comes out of your models.
New Plugin APIs
Two new plugin APIs are planned for 12.1.0:
New navigation APIs
An extension to XPLMAvionics so add-ons can create their own glass screens.
We are still putting finishing touches on the avionics APIs now, but this tech is very close to complete, and definitely usable.
Unfortunately we will not have a low level weather API in 12.1.0 – R&D on this is ongoing, but at least in better shape than it was before due to fixes to the internal weather code.
At the X-Plane Developer Conference in Montreal this year I gave a presentation sharing my thinking on our next-gen scenery system. This has created a lot of interest but also a lot of confusion. So in these next two blog posts I want to start by clarifying two fundamental ideas about scenery.
Here’s the key point for the first one:
A new scenery format is not the same as new scenery.
This can be confusing because we haven’t changed either our scenery file formats or our scenery in quite a while, and often the two change together. Let’s break this down.
A scenery file format is the way we represent scenery in our simulator. It consists of several things:
A file format specification, describing how scenery data must be encoded.
A file parser inside X-Plane that can read those files.
A renderer inside X-Plane that can render those files.
Tools that help people encode those files.
My first work for Laminar Research (two decades ago) was building all of those things: I invented DSF files, wrote the DSF reader inside X-Plane (DSFLib), worked on the rendering engine, and created the tools to write the files (DSFTool).
When we talk about just the scenery, this is the final rendered files that people fly with. Remember when we shipped 60GB worth of content in 12.0.9? That was new scenery rendered out with all the latest and greatest data.
X-Plane ships with the “global scenery” – a set of about 18,000 DSFs that ensure land everywhere from 60S to 75N. But this is not the only scenery out there – there’s TrueEarth, HD base meshes, SimHeaven, and scenery made with Ortho4XP.
Lots of people can make scenery, often in many different ways (using land class, orthophotos, autogen, etc.) but all of that scenery must be in X-Plane’s scenery file format, e.g DSF.
The scenery is the turtle and the scenery file format is the shell. The scenery can only be as complex as there is capacity in that file format (shell).
So the first part of my talk was a tour of how we have outgrown DSF, and pointed out that there are some things that DSF can’t do. For example, several add-on makers want to stream custom scenery, but DSF makes that basically impossible. DSF also isn’t meant for really high detail vector data, so we’ve been having trouble using all of the latest OSM imports.
The second talk discussed our plans for a replacement to the base mesh file format, which is based on raster tiles. This part of the talk said nothing about what kind of scenery we (Laminar Research) would make, which raised a lot of questions.
But now that you understand the the turtle and the shell, you have a lens to understand what we’re saying. This wasn’t an announcement of next-scenery, only an announcement of a bigger shell that will make that next-gen scenery possible.
So the next-gen scenery format is all about potential. The scenery file format limits what is possible for all scenery (both what is built into the sim and add-ons), so we want to raise those limits quite a bit in the next-gen base-mesh format.
The way we are doing that is by moving the base mesh from a vector-centric approach to a raster-centric post; I’ll break that down in another post.
After the X-Plane Developer Conference in Montreal this weekend (thanks to everyone who came and especially ToLiss for hosting/making us feel totally at home in Montreal) I thought “I should probably post something to the dev blog talking about what we’re up to.” I logged in and saw…I haven’t posted anything in four months.
So that’s not great. The truth is the X-Plane team is larger than it was in the v10 days and I spend most of my communications time talking to the internal team and third party developers.
I’m going to try to post once a week here. This sentence may be an embarrassing monument to lofty but impractical goals in another four months, but putting it in writing is a way to commit to it, and it won’t be the most embarrassing thing I’ve ever done.
Two Quick Store Notes
We announced the X-Plane Store plan in Montreal; Dellanie’s got a great FAQ there, but here for developers I just want to make two points clear:
We are not locking X-Plane down. I totally get why people might think this because the iPhone app store is (1) a very prominent way to do in-app purchase and (2) the iPhone is locked down. But we are not doing that. All of the ways you get stuff into X-Plane will still work, including add-on installers, dragging folders around, you name it. Going through the store is not a requirement, and everything that works now will keep working. You won’t have to pay for freeware or re-buy anything.
You will not have to be online all the time. Our current policy is that if you have an online license (an “XDD key”) you have to log in every two weeks or more to renew it. We are not going to switch to “all online all the time” – we know that this is impossible for a lot of our users and we consider maintaining this “renew the key every now and then” policy to be a requirement.
What’s Next: 12.1.0 and 12.2.0
We have two “big updates” planned right now:
12.1.0 will ship next and is primarily a graphics release. RCAS, bloom, DoF, shadow softening, cloud shadow fixes, new decals, you get the idea. This update will also address a number of real weather bugs and transition to the new real weather servers.
12.2.0 will ship after 12.1.0 and is primarily a flight model release. All of Austin’s advancements in prop blade dynamics, stalling and turbulence, etc.
Both releases will have a bunch of other stuff too; they’re big patches. I’m pointing to the graphics/FM divide because the decision to push one of graphics or physics in each patch is intentional to keep the scope of the beta under control.
We are aiming to get 12.1.0 into private testing this month.
What’s Up, Docs?
Probably only three people on Earth care about this, but after a decade (more walk of shame) I was trolled into updating the .net file format specification. So if this is interest to you, I apologize both for the delay and for the pain you are about to suffer. The road art file format in X-Plane is incredibly complicated and I don’t actually recommend anyone try to hack it, but it’s also not meant to be a secret.
Scenery, Now and Future
I am working to get water and orthophotos sorted out, hopefully for 12.1.0. We will also have a DSF recut (hopefully for 12.1.0 but maybe for 12.2.0) to address gateway airport boundaries and runway undulations.
In Montreal I discussed a little bit about the future of the X-Plane scenery system, but that’s complex enough to warrant another blog post.
The next X-Plane update will focus primarily on flight-model and systems, plus external-visual networking and some ATC features. While that update is in beta, we can work in parallel on real weather and graphics.
But there are two graphics bugs we already have fixed in-house which should relieve some 12.06/12.07 pain:
Running out of memory mid-frame. Turns out if you got into a fairly tight situation VRAM wise (and we try to do that to max out the texture res you can have) then X-Plane might run out of memory trying to draw trees and…melt down like a toddler who can’t have any more candy.
We have an interim fix: allocate memory statically so we always have it. In a future update we’ll reuse memory from other parts of rendering to be more efficient.
Popping out a window causes a big slow-down. When the arrangements of windows changes, we might need to allocate more VRAM for rendering. This is not a fast process – we have to halt all rendering, throw out the old memory, compact things, allocate new memory, and if a DSF is loading while this happens, the DSF loader is using up memory as we are trying to reallocate the windows, which can mean compacting memory again, paging down textures…you get the idea.
The fix is pretty simple: don’t do this if the popped out window doesn’t require more VRAM. Most of the time, this is the case, so this is an easy fix for a silly bug.
Integration work for the next update is going on now and I’m hoping it will be done next week. More details soon!
Editor’s note: what follows is very, very, very, very, very silly.
Last week we shipped X-Plane 12.06; since then we have found a few straggler bugs; like typical lARRge patches from the days of X-Plane 11, a few bugs escaped us until after final, including some crashes we could see in the auto reportARR.
While it’s not great to be shipping a “hot patch” to our release, it is pretty fantastic to announce X-Plane 12.07 ARRsea 1 on International Talk Like a Pirate Day (the 19th of septembARR). The rest of this blog post only gets worse; you’ve been wARRned.
12.08 Is The New 12.07
Internally, nobody is happy about this, but the hot patch bumped all of our version numbers. So the new road map looks something like this:
12.07: hot patch of 12.06.
12.08: coming soon. Flight model and systems, ATC and Networking
12.09: more graphics and real weathARR fixes.
12.08 (né 12.07) is almost completely integrated and should be ready for private testing as soon as 12.07 is settled.
Why Wasn’t I Notified
Since 12.07 is a new version, you won’t be auto-updated to upgrade from 12.06 while 12.07 is in testing; run the installer, update with “get betas” checked and you can get 12.07.
Crash Fixes
12.06 shipped with more sensitive internal detection for numeric problems. This is how we run the sim internally all the time – the goal is to find and squash bugs fast.
Unfortuntately there are sections of X-Plane’s simulation that are:
Not present in an aircraft (e.g. the real aircraft doesn’t have X)
Not expensive to run, CPU-wise
Not visible to the user (since the aircraft has e.g. no gauges to show these systems.
As it turns out, these systems are often happily running away in the background producing absolutely bonkers values; with sensitive numeric checking, the sim can crash due to problems in a system that nobody cares about.
For 12.07, I solved the problem by muting the alarm. My expectation is that we’ll have sensitive numerics in most betas, turn them off in the releases, and work through the systems code over time. (The priority on this isn’t super high because the systems aren’t consuming framerate – if they were we’d see them in our profiling.)
The other area where we saw increased crashes was with TCAS plugins. 12.07r1 has better logging and shouldn’t crash as much – the goal here is to not brick third party add-ons.
Other Bug Fixes
Multi-monitorARR: data output was not working in full screen configurations, fixed now, and manipulators work for multi-monitor systems.
OpenXARR: HP Reverb fixed, and we finally figured out why the white board would sometimes disappear. (It wasn’t gone, it was just 20 km from the hangARR.)
GARRmin Bezels
X-Plane does not have a built-in way to remove the bezels from the pop-out avionics. To solve this, some of our user and some add-ons edit the ARRtwork inside X-Plane’s “resources” folder, setting the bezels to clear.
X-Plane 12.06 introduced new bezel variants for the G1000 to cover all of the real-world panel button configurations. This fixed the bug “the real aircraft does not have these buttons, but when you pop the panel out, the buttons appear and do nothing.”
A side effect of this is: those aircraft using the new bezels use new art files, so the hacked up no-bezel art files on longer work.
This is not a bug for us to fix; if your add-on works by modifying the internals of X-Plane, we cannot guarantee that it will keep working even when we change the sim. (The only way to make that work would be to never change the sim.) You can work around this by modifying the new bezel files.
In the future, our plan for this is to provide a real way to hide bezels in the sim as a built-in part of the UI, which should make hacking unnecessary.
What Comes Next
Hopefully 12.07r1 will be “one and done”; if so, we’ll move on to private testing of 12.08 almost immediately.
If you are a third pARRty and your add-on has problems with 12.06, please tell us four weeks agoas soon as possible!
