Author: Ben Supnik

Finishing 12.1.0 Features

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.

Posted in Development by | 5 Comments

We Are All Raster-farians Now

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.

Posted in Development, File Formats, News, Scenery by | 27 Comments

A Few Notes on 12.1.0 for Developers

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.

Posted in Development, News by | 18 Comments

The Turtle Needs a New Shell

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.

Posted in Development, File Formats, Scenery by | 25 Comments

Blog Post Walk of Shame

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:

  1. 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.
  2. 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.

Posted in Development, News by | 33 Comments

Two Pain Relief Fixes Coming Soon

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!

Posted in Development by | 34 Comments

X-Plane 12.07 ARRsea 1 Has ARRived

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!

Posted in Development, News by | 25 Comments

X-Plane 12.06 – Third Time is a Charm

A few quick notes on 12.06-related chaos – it’s been a weekend.

Global Airport Errors

“Don’t rock the boat in a release candidate.” This is the lesson I should know, since I have cut at least 187 of them.

In 12.06rc1, we were missing HEKA (completely) and all of the airports at KLAS; the KLAS problem was due to a missing art asset. One of the multiple confounding factors in this bug is that the global airports don’t put up a “there was a problem with the scenery pack” pop-up message when art is missing. So, being the brainiac I am, I went “oh, that seems dumb, we’ll never know if the pack has problems, I’ll go fix that now”.

For 12.06rc2, I changed the policy so that the global airports would get a pop-up message like any other scenery pack that’s missing art.

As it turns out, the global airports are missing lots of objects – and probably have been for the entire X-Plane 12.0 run.

So coming soon to an installer you: X-Plane 12.06r3, which will be just like r2, but with the pop-up message turned off (just like the rest of the beta has been).

We have a more comprehensive plan to address these art asset issues for 12.07 – I’ll comment on why it’s important that missing scenery assets be errors in another post.

As a side note, it appears the most RCs we’ve had is X-Plane 9.40, which got up to release candidate 16 and took at least six weeks.

NVidia Users: No Zink For You (for a little bit)

In X-Plane 12.06r2 we have disabled Zink for NVidia users. We did this because there is an NVidia driver bug that interacts with Zink that will cause the sim to crash.

NVidia found the bug, is working on a fix, and they are quite responsive in pushing driver fixes. As soon as the fix is in non-beta drivers, we will change this from a “zink is banned” to a “you must have at least driver version x.y to run zink” message.

If you really really really want to run Zink on your NVidia card, you can still can, using these two steps:

  1. Raise your right hand and repeat after me: I, _____, solemnly swear that I want to crash my copy of X-Plane by running Zink with NVidia drivers before the driver fix is available. Let it be known to all of the X-Plane community that I do this of my own volition. I enjoy having my flight end abruptly with a crash report dialog box on short final, and I will not complain about this on r/flightsim.
  2. Run the sim with --zink

AMD users: you are not affected by this, so Zink is still available. Enjoy this rare chance to make fun of your green team compatriots.

We Put the ‘No’ In NOAA

Over the weekend the real weather servers went down. While we usually blame NOAA for this kind of thing, this one was super embarrassing: the server ran out of disk space (and the disk space monitor didn’t notify our ops team). The ultimate cause, I suspect, was that it was labor day weekend in the US, e.g. “a really good weekend for infrastructure issues.”

This isn’t the first real weather outage we’ve had this year, and for this reason we have a replacement weather server in development. The replacement will be able to serve the least old weather correctly when NOAA has a maintenance outage (instead of just 404ing everyone) and will hopefully clean its cache out correctly.

(The caching problem is slightly harder than it sounds: we do want to retain some old real weather files for test cases and bug reproduction. But we need to purge most of it to keep the server from filling up.)

What’s Next

If 12.06 rc3 is final, we’ll let it sit a little bit and then start private testing of X-Plane 12.07. The X-Plane 1.206 beta has taken quite a bit longer than we wanted, so 12.07 is intentionally a smaller release – about half the size in terms of code change. That’s still a lot of new stuff (and a topic for yet another separate blog post).

If 12.06rc3 is not final, I will set myself on fire.

Posted in News by | 50 Comments

Please Auto-Report Your Crashes

X-Plane 12.06 beta 4 is out – we pushed for a second beta this week because I’ll be out of the office next week and the installer-making machine lives in my basement, so beta five will hopefully be in about ten days. Here’s some release notes.

The team has fixed a bunch of big bugs this week, including water flashing, clicking problems with mouse-flies and a bunch of crash bugs.

The Crash Reporter…Crashed?!?

XPD-14312 was a meta-bug: the bug was that on Mac, when the sim crashed, it would hang instead of showing the auto-crash-reporting box. I’d like to use this bug as an excuse for a public service announcement:

Please always auto-report your crashes.

Our crash reporting system automatically de-duplicates crash reports but also counts the number of crashes and can tell us the number of unique users affected; we count on repeated reporting of the same crash to get a picture of the most severe crash bugs affecting the entire community. By always reporting auto-reporting the crash, you’re up-voting the importance of fixing the crash and giving us valuable insights into what’s hurting our users the most.

Do I Need to Also File A Bug?

The short answer is: no. If you auto-report a crash you do not need to file a bug.

Filing a bug can be useful if you have exact reliable steps to reproduce the bug. In this case, please file the bug, include the clear steps to reproduce, and include a Log.txt from after the crash was auto-reported. These crash logs will have a “crash UUID” at the end that lets us locate your crash inside our system.

Please do not file a bug for a crash if you do not know how to reproduce it. “I was flying and the sim just crashed, I don’t know why” provides us with no useful clues; everything we can act on is already in the auto-crash report.

What’s Next

We’re trying to wrap 12.06 up; the rest of the beta will focus on a few more rendering bugs, weather bugs, and VR bugs. While we are not going to do a massive real weather overhaul, I do have to fix the bug where it rains for no reason.

Posted in News by | 7 Comments

X-Plane 12.06 Is Full of Many Things

X-Plane 12.06 beta 1 is here! And it contains a lot of changes. Here’s a few of the bigger things we changed, and a few notes about the beta process.

Clouds and Weather

Since X-Plane 12.0 shipped, we’ve been working on the clouds and the weather system to improve performance, accuracy and quality. 12.06 ships the first two steps in this multi-step process:

  • The cloud shaders are now faster and have fewer artifacts. Daniel rewrote the way clouds are marched, fixing zebra stripes and generally making things less pixelated and ugly.
  • The cloud shaders also contain a dedicated path for cirrus clouds that should look better than what we had in 12.0 (“really thin stratus clouds up high”).
  • Alex and I rebuilt the noise functions that build each weather type to get better looking clouds of all types.

While there are a few real weather fixes included, we have not tried to comprehensively update real weather; my thinking was that without proper rendering, it would be impossible to tell if real weather was actually getting better.

Coming soon: “Minecraft clouds” (e.g. square cubic clouds, especially with real weather) should be fixed in beta 2, so enjoy them while they last. Thick prism-shaped cirrus clouds should also be fixed, and we’ll be tuning up the presets and METAR parsing.

The future: we are looking at putting a 2-d “cloud shell” behind the 3-d clouds to handle orbital view and make the planet look less silly, and we’ll be going over real weather with a fine tooth comb.

Lighting

X-Plane 12.06 fixes some constants for sky colors but is not a lighting update. We have a bunch of lighting fixes internally, but the plan is to measure twice and cut once, e.g. make one patch to update lighting once we have all of the changes.

Improving dark cockpits is high on our todo list, but we also don’t want to tweak the light levels in the cockpit over and over and over, thrashing third party developers each time we do it.

My expectation is that when we recalibrate cockpit lighting, minor aircraft updates will be needed, but third parties who have chosen to “fix” cockpit brightness themselves (by adding extra light or hacking materials) may have to undo their hacks. I’ll try to provide clear guidance and early builds when we get to this point, but lighting is still “in development”.

Rendering and VRAM

The biggest change to X-Plane 12.06 is not one you can see: we’ve converted the main rendering pipeline from 12.0 (which was hand coded) into a rendering node graph.

Rendering graphs are all the rage today; if you’re curious about this you can look at something like AMD’s Render Pipeline Shaders. But here’s the why behind this change:

The render graph allows us to double-book VRAM used to render the main frame. X-Plane 12 has a lot more stages and processing in its pipeline than X-Plane 11, and that was consuming VRAM.

In 12.06 we treat VRAM more like an AirBnB and less like a second home – at different times in the frame different parts of the pipeline are using the same chunk of VRAM, which means we need less VRAM in total for effects. This change wasn’t possible in X-Plane 11 – you can’t double-book VRAM with OpenGL.

But it also would have been too tedious to hand code aliasing – the rendering node graph automates most of this and prevents bugs.

Coming soon: we have a performance optimization for beta 2 that should help CPU-limited users.

The future: in the future the rendering node graph will also let us render different parts of the frame using different CPU cores, for better CPU utilization and higher FPS for CPU-bound users. We still have a lot of work to do on this front, but once again the rendering node graph makes it possible.

ATC and AI Aircraft

12.06 has a lot of ATC improvements – months of Jim’s work went out in beta 1. I’ll try to get Jim to write up a detailed blog post on the details.

One big improvement to ATC: Austin fixed a lot of problems with the AI pilot. This affects ATC because the AI aircraft fly more reliably and are less likely to crash and bring airport operations to a halt. We’re expecting stability improvements because numeric instability from AI aircraft crashing into mountains would sometimes crash the entire simulator.

The future: Jim has more ATC fixes coming and is working on SID/STAR support.

What Comes Next In the Development Pipeline

X-Plane development works as a pipeline: as I type this…

  • 12.05 is shipping
  • 12.06b1 is in public beta
  • 12.06b2 is being internally tested before going public
  • 12.06b3 is in development – about half of the beta 3 bugs are fixed and we’re working on the rest.
  • 12.07 development is almost finished – a mix of development and testing are going on right now.
  • We’re working on features for 12.08 and beyond.

Third parties: I believe all of the known third party compatibility bugs are scheduled to be fixed in beta 3, and most of them are fixed already. But these fixes missed the cutoff to get into beta 2, which was a few days ago. We’re hoping to get beta 3 out early next week.

We try to not hold up a beta for fixes that are almost ready – if we did the betas would never ship because there’s always one more fix that’s almost ready.

The future: Pawel’s been working quite a bit on the networking stack, and his first changes will ship in 12.07, primarily targeting pro-level customers. We also have more graphics changes coming, and some of Austin’s flight model improvement are in test right now.

Posted in News by | 66 Comments