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.
World Editor 2.6r1 is now available. This is the first release candidate, for which we encourage you to explore before we lock it down for release! Version 2.6 packs quite an extensive feature list. Features include :
New Shape Entities
Allowing users to define lines and polygons, and then export to .kml or .osm for use in third-party tools!
Polygonal Exclusions
A highly requested feature! (Note, these do not work on forests in current-gen scenery. The default behaviour will instead treat the defined exclusion as one large bounding box)
Terrain Objects
Some of you may have noticed that the terrain for TNCS and TFFJ in 12.1.2 looks a bit more defined. This is somewhat of an illusion, as we are still using the same base mesh that shipped in 12.0.9.
Terrain objects are designed to interface with orthophotos and create small scale 3D details.
*This is NOT a replacement/new/next-gen system for mesh-editing. But rather an additive tool that can help define more awkward structures
Dual-docking Jetway support
Another highly requested feature, WED can now support dual-docking jetways. Existing sceneries are NOT automatically ready, and must be defined by an artist first. Thanks to Michael, in a future version of X-Plane, we will push a new Gateway cut with some demo airports that are ready for dual jetways. These include (*subject to change):
Strings can now be defined down to the centimeter, instead of the meter… allowing for more accurate object spacing.
For WED newcomers
In the past, whenever users have attempted to open a scenery pack without an .XML file, all you got was an empty project. This was obviously confusing to users who did not know how to import the scenery files in. Now in WED 2.6, we analyze what is inside your scenery pack and offer to import the relevant files for you. If starting from a completely blank project folder, we now also give you the option to download directly from the gateway! These changes should help newcomers and seasoned artists get stuck into a project with ease!
Misc
In addition, a number of UI enhancements for users have been made available.
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.
The X-Plane 12.1 release candidate is out today!* The last twenty four hours have been a mad dash to get the release candidate posted before we head to Las Vegas for FlightSimExpo 2024. If you are attending, stop by the X-Plane booth – there will be a bunch of us there including myself, Austin, and Marco, our new release manager.
All of this is a little bit exciting because we can’t recut the release candidate while in Las Vegas – one of the machines involved still requires a human to sit in front of it. We’ve been racing to get the RC done while we still have access to those machines, and the build system responded as you’d expect – by failing in all sorts of new ways. My plan is to just not breathe until I’m on the plane tomorrow.
(*) Because this is a release candidate you still have to check “get betas” in the installer to opt in to getting the RC; once the candidate has been out for a week, if nothing huge goes wrong, we will declare it final and it will become the official update for everyone.
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.
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.
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!
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:
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.
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.
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”!
