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 | 21 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 | 34 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

ATC changes in 12.06 and beyond

Jim Keir here – today I’m going to talk about what’s been going on with ATC for the last six months or so, and what’s planned for the near future.
You’d be forgiven for thinking that the answer to the first is “not much”, simply because there’s been very little visible in the release notes for ATC, but that’s definitely not the case. Normal work on bugs and small improvements has been going on as usual, and 12.06 contained quite a backlog of these which I’ll go into more detail about below. Normal progress has been slowed, however, by time spent on adding one huge new feature. More on that later.

First though, a quick peek behind the curtain. This is a very high-level list of the changes that went into 12.06, now with added explanations! I’ve removed about half of it because they were maintenance, corrections to previous changes and other non-visible things, and edited some of the rest to protect the idiot innocent. Many of these changes, especially the ones starting with “Merge branch”, would be made up of many changes themselves and could cover days to weeks of work; others might be a change to a single letter.

New in 12.06

  • Fix incorrect voice phrase for requested altitude change
  • AI had a stupid max speed under “AI flies” at key points on the ground which was never reset
  • Fix unwanted transmission possible during spawn of AI on arrival.
    This simply clogged up the airwaves for the first minute or two of your session.
  • Fix for descent time calculations
  • Merge branch ‘fix_XPD-13780_Pushback_Messages’
  • Merge branch ‘fix_XPD-13783_Pushback_Dialog’
    These two should make the text messages and buttons in the pushback dialog clearer and more consistent with the current state. Note that you can also request pushback by radio, from ground or tower.
  • Modify altitude monitoring to try and remove inappropriate warnings
    This is a long-standing bug with repeated altitude correction calls from the controller, when you were already at the right altitude. Since this change I finally got a log from a bug report that let me nail the main cause, and a final (?) fix should hopefully be included in 12.07.
  • Allow editing of ATC flight info if required information is missing, even if a flight is under way.
  • Take two for the “AI not calling downwind” bug.
    AI may not always have called downwind. They still called final and landed correctly, this was just a missing radio message.
  • Merge branch ‘fix_tropo_jumps’
    People flying airliners found that their altitude was suddenly changing during cruise, sometimes by hundreds of feet, making their autopilot want to take a bit of a lie down in a dark room. This turned out to be two subtle bugs in creating the atmosphere’s vertical temperature profile, where it was possible to get a sudden change instead of a smooth gradient. It depended on your precise location and altitude, and having real weather which had specific temperatures at very specific altitudes.
  • Latest airport names and combined voice changes from several branches.
  • Merge branch ‘fix_XPD-13873_Wake_Sep_On_Runways’
    ATC will now delay your departure clearance until the wake from the previous aircraft, whether arriving or departing, has reduced to a safe level for your aircraft.
  • Merge branch ‘fix_XPD-13842_Departing_AI’
    The calculation for the time you would take to line up was just plain broken; sometimes it was too long, sometimes too short. This affects AI as well, of course, so this one fix should prevent you being told to line up with an A330 on short final, and also reduce AI go-arounds. It also now takes account of how far the hold-short line is from the start of the usable runway, and whether there are any sharp corners.
    Why wasn’t this seen before? Because the estimate wasn’t always way too long or way too short. Sometimes it could be just right, and the airports that habitually get used for both manual and automated testing by total coincidence were just right. This one also only was able to be found and fixed after someone sent a logfile with full details.
  • Merge branch ‘feat_XPD-12784_multi_channel_atc’
    This one’s a biggie. I’ll talk about it separately.
  • Merge branch ‘feat_ATC_AI_TCAS_Awareness’
    ATC is now aware of TCAS aircraft – read “plugin-controlled AI” – when checking your line-up time against other aircraft using the runway to work out whether to give you departure clearance or not. This means that third-party AI aircraft systems should play a little more nicely with ATC, with no changes required to the plugins.
  • Contact nag was broken entirely.
    Fixes the “Are you with me” if you are handed off to a new controller, change frequency but forget to check in with them.
  • More AI-flies changes for specific situations. Alter the test to account for fake-flow changes.
    A lot of testing is done using AI aircraft, and the “AI flies” mode for the main aircraft. Getting that transition from human to AI done and having the AI pick up an aircraft mid-flight in any state whatsoever, is not simple! This also shows one of the automated tests being changed because it correctly failed as a result of another change.
  • Fake calm flow was only using one runway even if multiple valid runways existed.
  • Allow “Missed Approach” earlier during the approach.
  • Speech for airport names not being generated if the apt.dat has no country code set for that airport
    Airport designers, please use correct ISO country codes! “USA”, “U.S.”, “America”, “Amercia”, “U S A”, “US of A” and so on.
  • Fix several problems with missed approaches
  • Add option to file and send plan to FMS, and to transfer plan from FMS
    Simple quality-of-life change for the “File a flightplan” tab in the ATC dialog. If you’ve set your FMS, maybe from a file downloaded from an online planner, you can now transfer your route to ATC in a single click. Likewise, if you’ve asked the ATC dialog to plan a route, you can send that to your FMS. Of course, you’re free to program your route into the FMS manually as before.
  • AI did not avoid user if parked on the end of the runway with no ATC interaction
    If you start a flight on the runway ATC is aware of you, you will be ‘owned’ by tower and cleared for departure. The AI, however, didn’t get the memo until you made your first radio call. Oops.
  • Further fix for OnRunwayStartMegaHack – was dependent on immediate radio access
    On-runway starts are an absolute bloody nightmare to handle! In this situation, a bug with the 737 where the radios would be unavailable for a frame or two after the sim started totally broke the AI.
  • XPD-13764: Approach clearance cancellation was not being spoken
    You’d be given go-around vectors, but not told that your approach had been cancelled, or why.
  • Synthetic flows now align to the longest runway instead of using NSEW
    When an airport definition has no runway flows defined, the sim has to invent them. Previously five flows would be created, one each for the cardinal directions and one for calm conditions. This change has the fake flows offset by the direction of the longest runway, which would usually be aligned to the prevailing wind. Hopefully this will reduce some of the valid “You’re using what runway, now?” questions – but not as effectively as airport designers actually adding flows to their airports!
  • XPD-13788: Approach cancelled if perfectly on straight-in approach a long distance away
  • Another runway-start fix for switching to AI
    I hate runway starts.
  • Route planner will consider great-circle sections
    If you ask the ATC dialog to auto-route between two airports, it was previously only considering airways or nav-to-nav. Turns out there are no defined airways across the north Atlantic, and flights from KBOS to EGLL were flying halfway down Brazil before crossing the ocean… Now it will try to pick this up and use a DCT section if following airways looks silly…
  • XPD-10555: AI can fly great-circle routes without continual corrections
    … which means the AI need to be able to actually fly them. Normally AI pop in and out of existence quite quickly and this wasn’t that noticeable – right up to the point where you ask the AI to fly a long route. Now they fly the great-circle route correctly instead of picking a straight-line heading to the destination and jink back onto the correct course every five minutes or so. This had fun consequences for trans-polar routes too; send an AI near the poles and they would just fly around it forever.
  • XPD-13768: Route generation can create routes which go past the destination, and can choose the wrong fix where multiple with the same name exist.
    Two fixes here. First, if you asked ATC to auto-route to a destination, it could be that the best fix to head for was actually beyond the destination, which makes no sense as an actual route. That was discovered at the same time as finding that in some places, two different fixes with the same name exist within a few tens of miles of each other. That feels like a bug in reality to me, but there you go.
  • XPD-13767: Crash when filing from an airport with no radio facilities
    Good ol’ fashioned crash bug. For 12.06, requesting IFR clearance on the ground from an untowered airport is disabled because the system was never intended to handle it.
  • XPD-13762: Global region now uses mbar instead of inhg for pressure.
  • XPD-13759: Adjust descent rates used to predict descent timing
    Please, folks, don’t use the “Request altitude change” over and over to manage your descent! Either wait for ATC to call it, or specifically request descent. Either way, this change pushed the decision for ATC to initiate descent out a bit.

Now for the big change – ‘feat_XPD-12784_multi_channel_atc’. This one’s been queued for quite a long time. Until now, radio frequency use was handled very simply. All controllers would both transmit and receive on all of their allocated frequencies at the same time, and you’d always be told to use the lowest frequency in their list. For small airport towers they probably only have one frequency, but for approach and regional controllers they may have more than one. In fact, some especially large controllers have dozens.

Also previously (i.e. X-Plane 11), everyone being on the same frequency really didn’t matter. AI was used less, ATC was definitely used less, and also had a lot less to say. In X-Plane 12, though, that’s changed. If you’re using both AI and ATC you’ve almost certainly found that near larger airports or even just flying cross-country legs with a controller covering a large area, you just can’t get a word in edgeways. This leads to missed turns, inability to make time-sensitive requests, avoidable go-arounds and other assorted havoc – and that was with human radio time prioritised over the AI. 

It was even worse for the AI because they are totally dependent on ATC instructions, so even short delays can put them into a situation where they suddenly need a burst of revector instructions – which increase radio load further. You can see where this is going.

With this change, a controller will actively manage frequency allocation. Instead of everyone always transmitting on a single frequency and the control facility simul-casting on all frequencies, aircraft will be allocated to other frequencies based on both anticipated and actual load. This means that, while you might still end up waiting for a burst of radio traffic to go away, you should be able to speak without too much of a delay. You might also, of course, be asked to change to a different frequency yourself (or, in betas 1 and 2, continually given this call… my bad, fixed for b3).

To be clear, this isn’t a full model of controller sectors, we just don’t have that data available. If you think of it as ‘sectors-lite’, where there are aircraft around you which are being directed by the same control facility but different staff within that facility on different frequencies, you won’t be far wrong. The short version, I hope, is that one of the key frustrations with the ATC system, a valid frustration which I saw people saying simply stopped them using ATC at all, should be gone.

And for the future? Normally of course we don’t go into too much detail about what’s planned unless it’s a hot topic, simply because shit happens and things that are planned, even if the code’s done, don’t always make it in to the next release. Or the one after that. Just this once though, I think it’s worth a little glimpse of what’s going on, just to show that outward signs of (in)activity can be misleading!

First there’s another list of fixes and improvements to come. As with the 12.06 list, here’s some of what I’m hoping will be in a very near-future release. Also as with 12.06, this is cut down and edited a little.

Coming in 12.07 (ish)

  • Ensure we issue altimeter setting for aircraft that start in the VFR/IFR approach position (i.e. 3NM/10NM from the runway, airborne).
  • XPD-14246: Fix discrepancy between flight model and ATC ISA altitude
    This is part two of the “stop whining about my altitude” bug.
  • Prevent flow changes while any aircraft is on zone 2 or higher, instead of just on final.
    You should be less likely to be revectored for a different approach if you’re already approaching.
  • Merge branch ‘feat_Untowered_Flightplan’
    This adds the ability to file an IFR flightplan with a regional controller, while on the ground at an untowered airport, including timed departure.
  • XPD-14239: Radio calls used correct indicated altitude even if altimeter setting was wrong
    When you called to check in with a controller, the altitude spoken by the pilot if you were below the transition layer was the correct one even if you’d not set your altimeter correctly.
  • Any airport with procedures can’t be a FISO.
    Airports with some kind of radio support can be full ATC or FISO. This was new for X-Plane 12 so, while this can be set per-airport in WED, most don’t have the information set about which control type they are so the sim has to guess. This simply says that if an airport has SIDs or STARs, it’s going to fully controlled.
  • Fix Austin’s AI switching control modes at intermediate hold-short points
    AI might behave differently after crossing hold points while enroute to or from the active runway.
  • Fix rotating the aircraft using the compass in the map in pause mode
    OK, I admit it, this one’s for me. I use this constantly, when testing. Previously if you used the map to change your aircraft’s heading in pause mode, the heading reset if you then changed anything else. Now the heading sticks.
  • XPD-14193: Request diversion mentions the previous destination instead of the new one.
    Duh-level typo
  • Uncertain of Position wasn’t always available when it should have been.
  • XPD-14192: Ensure the AI closes *all* aircraft doors, not just the ones it would have opened itself, when service completed.
    Yet another switch-to-AI oddity, when an AI would taxi and depart with doors open if a human opened them and the AI wouldn’t have.
  • XPD-14190: Don’t continually regenerate fake flows except at load time – if the flows are unusable, this never stops.
  • XPD-14189: LSO left/right commands were reversed
  • Disable most ATC functions in external-visuals machines.
    Only the main computer handles ATC, so why waste cycles?
  • Additional condition for allowing on-runway flightplan editing.
  • Add “Departure clearance cancelled”
    If you’re on the runway with takeoff clearance and then request taxi to parking – forgot your lunch maybe – you’ll have that clearance explicitly revoked.
  • Make com[12]_[rt]x datarefs work on aircraft with no Garmin unit
  • Fix altitudes in ATC check-in calls
  • Potential fix for being unable to contact ATC at all after cancelling services
    If you cancelled IFR in-flight then, depending on the exact state when you did it and what you do next, it was possible to end up in a situation where you couldn’t call any controller at all.
  • Change some ATC calls to allow use as VFR when filed but not cleared.
    Related to the previous bug. If you filed a flightplan, the only valid action would then be to activate it by requesting clearance. If you didn’t make this request, and took off VFR/uncontrolled, some calls were blocked.
  • Fix double call for “Cleared to Land” for VFR flights to controlled airport
  • Allow request for a different parking spot when one is already allocated. Add new “TaxiIn” state.
    You can now request a specific parking spot even after ATC has allocated a different one.
  • Expand log for inappropriate radio frequency.
    Finally, this is an example of one of the “no visible change” bugs that I’ve removed from the lists. There is a very rare problem detected in internal testing, where the system flags that an AI is on the wrong frequency. Right now there’s no clear cause, so this just adds more logging around the warning – which doesn’t appear in public builds – to help find and fix this.

Hopefully this has given an idea of some of the impact of the changes that are already in place, and what those terse bullet-points in the official release notes mean. It might also give an indication of the graceful, swan-like visible progress (hah!) compared to the furious paddling that’s normally hidden below the waterline, and I think it’s fair to say the same for all of the developers and designers, not just me working on ATC.

Looking a little further ahead

Oh yeah, nearly forgot. SIDs and STARs. If the lists of fixes and new features above look a bit sparser than you’d hope, now that Ben’s officially let the cat out of the bag I can say that this is why. SID/STAR support is written – past tense – and about to hit a lengthy period of polishing and internal testing. The key word here being “lengthy” – don’t expect to see these in 12.07, 12.08 or twelve point whatever I listed last plus one – but SID/STAR support is on the way.

Here’s something to warm the hearts of the people who complained that an overhead join with three left turns was being “vectored all over the sky”!
Posted in Air Traffic Control, News by | 30 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