This may come as a shock to you, but… we hear a lot of complaints about the X-Plane 11 ATC.
I have good news: We want to improve the ATC!
The problem we’re facing is that a lot of the feedback we get is indistinct—hearing “ATC sucks” doesn’t help us understand how we could do better. So, here’s what we’d like from you: Tell us the specific issues you have, or the specific features you’d like to see implemented. At this point, we can’t promise a timeframe for any given improvements, but we can promise to consider everything you say.
Please note: Any comments on this post that don’t directly relate to ATC will be deleted. Moreover, please don’t slag on other people’s wishlists—arguments against other people in this thread will not inform our decisions about how we prioritize this stuff.
This version of WED has a lot more validation than past ones did, so expect your previously “good” airport to fail validation. In particular, WED now validates that hot zones have been properly used around all runways in the ATC taxi route network. Getting hot zones perfect is very, very hard to get right by hand; the validation tool is meant to help you find the problems.
Jennifer is working on comprehensive documentation on ATC taxi route authoring; I’ll link to it as soon as it’s done. Our hope is that with the new docs and validation, everyone can understand how to correctly set up ATC taxi routes, and get assistance from WED to get them right.
As some have noticed, we are not accepting uploads to the gateway from WED 1.5 betas. The issue is: if the validation code has bugs, then WED could (due to a bug) force you to upload an incorrect airport to the gateway.
I don’t know when we will allow uploads, but my guess is that within two weeks we’ll have a WED RC or final version that is ready to use.
For now your best bet is to use WED’s new tools to get the bugs out of your taxi layout and flows.
X-Plane 10.50 beta 7 is out. There are a few fixes that I hope make this finally a “solid beta”: no more flashing airport lights during the day, normal maps back on aircraft, and liveries should work correctly.
We have a fix in the works for tall buildings blocking the approach path at KLAX; I’m hoping to get that into beta 8 some time next week.
Creating New Apt.Dat Layouts
WED 1.5 beta 1 is out; please do not upload revised airports with WED 1.5 yet. If there are still bugs in X-Plane’s handling of the new apt.dat data, then you have no way of knowing what your airport will look like after we fix those bugs.
X-Plane 10.50 adds a new rule: AI aircraft will not be born or land at airports where there isn’t a parking spot wide enough for the aircraft to park. So if you have an airport with a 11,000 foot runway and no size-E or F parking spots, the 747 would have landed in 10.45 but will not land in 10.50.
AI aircraft will land even if the parking spots don’t match the needed aircraft type – in other words, if you have a size E parking spot for helicopters only, the 747 will still land (and try to park there). Here’s why I didn’t stop this case: without static aircraft, the equipment codes on parking spots is likely to have errors; it’s hard to know you get everything right. So if we start requiring equipment code matches to land an aircraft, we may end up with no AI aircraft at lots of airports.
Once static aircraft have been deployed and authors update their airports to use them, the equipment codes should become much more accurate, and at that point we can prevent the AI from landing if it can’t find an equipment code match on a parking spot.
We also do not limit landing by taxi route width; the assumption is that if you have a width-E parking spot, you have a width-E route to the active runway somewhere on your layout.
Starting with beta 7, you can now debug ATC AI placement decisions by setting the art control atc/debug/log_spawn to 1. After it is set, future spawning decisions will be heavily logged under the “ATC” log tag. If an AI isn’t placed at an airport, you’ll see exactly why.
Note that currently the takeoff/landing requirements for the aircraft tend to be inaccurate. (They are computed from some properties of the aircraft, not flight testing.)
From my examination of the small set of airports that I run across while debugging (with something like 3000 airports, I am at best “sampling” the gateway airports), it appears that authors don’t understand how ATC flows work. We’re working on new documentation to try to explain this, and I’m thinking that some very basic flow errors could be caught by WED. For example, I saw one airport that had this in WED:
This is almost certainly a mistake. This is a single flow for the airport that says “when this airport is in east/west mode, aircraft may take off or depart from either runway 9 or 27!” In other words, airplanes can use the runway from either direction at the same time.
I know of no real-world example where this actually happens, and if there is one, it has to be super-rare. The author probably meant to do this:
Wind rule: wind must be coming from the east
Runway rule: 9 (arrivals, departures)
Wind rule: wind must becoming from the west
Runway rule: 27 (arrivals, departures)
In this case, the airport is using either 9 or 27, but not both at the same time. A few things to remember about flows:
Only one flow is ever in use at a single time. That’s why a flow can have more than one runway.
All of the runways within a flow are in use at the same time when that flow is in use. So never put conflicting runways in a flow!
X-Plane picks the flow by looking at your flows in the order you put in WED. It takes the first flow where all of the restriction rules (time, wind, visibility) can be met. So put the ‘preferred’ operations for your airport first in the list.
If you have more than one rule of a type, only one must be passed. So for example, you can have a “rush hour” flow with two time rules, and it will be picked if either is picked. So you can make morning and evening. Similarly, you can make a wind rule for “strong from the east” and “calm wind” and if either is picked, the flow is picked.
If you provide no rule for a category, the flow is never disqualified by that rule. So if you have no time rule, the flow can be picked at any time.
Here’s two more art controls: atc/debug/rwy_flow debugs how X-Plane picks its flow – turn it on and then go to your airport and you can see in the Log why the flow was picked. atc/debug/rwy_selection shows how a runway was picked for an airplane given an existing flow.
One of the top 5 bug reports I see: two AI airplanes starting in the same ramp start position, or worse, an AI airplane starting on top of the user’s plane. The pictures are often quite spectacular, if not what we intended for the ATC system.
The code that allocates AI start locations is much improved for X-Plane 10.30, so in the next major update, we should get less cluttered ramp starts.
But the code change isn’t enough; there’s something that you have to do now if you are working on an airports.
You need to provide more than one ramp start! In particular, if there aren’t enough ramp starts for a given airport, X-Plane cannot sanely allocate AI airplanes with space between them.
In the past, X-Plane’s UI didn’t have room to show a lot of ramp starts, so authors would include only a handful. This has been fixed for a while, so I encourage you to add lots of ramp starts to your airports. This will give the AI planes room to park and the user a choice of all of the real-world gates.
Types of Ramp Starts
X-Plane 10 introduced type and equipment codes to ramp starts. One thing Chris found while working on the ATC system was that users were putting ramp starts in silly locations. For example, some airports have ramp starts on the active runway! He had to write specific ATC code to untangle the disaster that happens when an airliner decides that “on the runway” is a good place to park.
X-Plane 10 lets you define your ramp start as a tie-down, a gate, the interior of a hanger, or ‘misc’. The misc category was designed for ramp starts that might be interesting to humans (e.g. “in the run-up area for runway 7”) that are not appropriate for AI/ATC use.
I am not a fan of ramp starts near the active runway; I figure if a user wants to minimize taxi time, X-Plane lets you start on the runway, and a start anywhere but the ramp is inappropriate for realistic flight. But whatever you make, consider marking real parking spots as gates, tie downs, etc. and the random starts as “misc”.
Static aircraft (3-d models of aircraft that don’t move) are a nice way to make an airport look busier with less impact on framerate than AI planes. But this presents a problem: if a static airplane is at gate C4 and a user wants to park there, what do we do?
I believe the solution to this is to automatically place static aircraft based on ramp starts. This is not something we have coded now, and I don’t know when we will get to it, but my design idea for static aircraft is to have the airport include a lot of start positions and no static aircraft; X-Plane can then place static aircraft at ramp starts based on a rendering setting, with the user picking more static aircraft if hardware permits.
The advantage of this scheme is that (because X-Plane places the static aircraft), X-Plane would know where they were parked and could make sure the static aircraft aren’t in the user’s spot and the AI aircraft aren’t using a spot taken by the static aircraft.
The todo item for authors to someday support sim-placed static aircraft is, fortunately, the same thing authors need to do now to prevent future AI collisions: just make sure that there are a lot of ramp starts, modeling how the real airport works.
Edit: Just to clarify, 10.30 is not scheduled to contain a big pile of ATC bug fixes. The slight improvement in AI ramp start placement that I put in was a one-off bug fix; more ATC bug fixes will come in a later patch.
Now that we have user-contributed airports with buildings in X-Plane 10.25, I have a few topics to cover regarding airport authoring. The first is taxi routes. (I will get to the contribution and sharing process in a few posts – please bear with me.)
The short of it is: if you do not provide taxi routing in an airport layout, X-Plane will generate a taxi route, and the route X-Plane generates is not particularly good. The algorithm is slow, so it hurts loading time, it produces a relatively ugly layout, often with errors, so the AI behavior is bad, and I suspect that sometimes the whole algorithm crashes.
While all of these things can be improved, there will always be a trade-off between load time and algorithm quality. For example, the layouts could be rendered using more memory, but the loading would be even slower.
And we don’t want to be generating AI layouts – we want this data to be in the apt.dat where it can be built by smart humans who can carefully author.
For example, consider an airport with a huge tarmac, where the taxi routes are simply painted onto a big slab of concrete. The AI algorithm doesn’t understand this line structure at all – it isn’t smart enough to ‘get’ the taxi instructions. So the AI network lets the plane drive straight across the slab of concrete, traffic flow be damned! The AI also has no idea what any taxiway is named, so ATC can’t provide good route names.
The pictures above show the actual generated taxi layout at KJFK – red indicates active segments where the aircraft hold short before crossing runways. Nerds will recognize that this layout is created by a straight skeleton erosion algorithm, a strategy for analyzing images that comes from OCR.
The moral of the story is: while the AI taxiing behavior can be quirky, a lot of the problems come from X-Plane trying to auto-generate layouts off of the apt.dat file without a real taxi route structure. If you create such routes, the sim loads faster, provides better directions, and provides more plausible taxi routes.
I’ve just uploaded some new videos to the official X-Plane YouTube video channel. These videos are screencast tutorials for airport authors to help them understand the ATC Airport Flow feature in X-Plane v10.
ATC Airport Flows are essentially a set of rules that control how the runways are used for airport operations. An airport like Chicago’s O’Hare (KORD) for example has 7 runways (14 different takeoff/landing directions)! ATC does not simply put aircraft wherever they feel like in the moment or there’d be a massive aluminum traffic jam. They have a set of rules that control which runway(s) are in active and inactive at any given time. These rules are typically based on two main criteria: weather conditions and time of day.
In the real world, at major airports, traffic studies are done to decide which runway combinations are most efficient for traffic flow, safety and workload and those combinations of runways become active when the conditions are just right.
Once the controller deems certain runways active/inactive for the current conditions, there are yet more rules to determine which types of aircraft use each of those runways. For example, if a small Pilatus is flying into KORD, I strongly doubt they’re going to block up their major runways for arrivals for a small single engine turbo prop. They’re likely to put him on a smaller accessory runway. Also consider some airports which only use certain runways for arrivals while other runways are only used for departures. This is often done for noise abatement or obstacle avoidance. These types of rules can be included in the ATC Airport Flow.
Our goal was to give authors enough granularity to closely mimic the way real airports are run so that when X-Plane’s ATC is in action, it’s towers can make similar decisions to the real controllers.
Well as I promised (11 months ago), here’s a tutorial on making ATC Taxi Networks in WorldEditor v1.2. Hopefully this clears up some misunderstandings about how the pieces of the system work and how they’re meant to be used. Perhaps the next video tutorial will be on creating Airport flows to teach ATC which runways get used for which operations.
Announcements on the plethora of betas that went up this weekend.
Edit: beta 5 is temporarily offline while we resolve a missing scenery texture. So you’ll get beta 4 if you update.
X-Plane 10.04 beta 5 is now available. Release notes here. I think we will be winding down the 10.04 patch in the next week and going on to 10.05. There are a number of cosmetic bugs that I hope to get fixed shortly; it looks like they’ll have to go into 10.05 and not 10.04.
What’s the logic behind this patching? Basically we’re going to keep doing small patches until we get a certain set of bugs fixed – bugs that we think are important and that we can fix without tearing the sim to bits. The patch runs sometimes have to be closed off to burn new DVD masters* (this is the case with 10.04). In all cases, if you don’t want to deal with beta chaos, you can ignore the betas and get a new patch every few weeks with a little more performance and a few more bugs fixed.
I spent some time yesterday retuning cloud performance and the effect of the cloud rendering setting. Besides trying to find a better performance-quality trade-off point, the old slider had way too much range on it. It defaulted to 50%, but that 50% point really represented “a good setting for a high end gaming desktop”; going past that would put you into the range of “this isn’t ever a good idea, but the engine can do this without crashing”. The side effect was that running at 25% clouds (a very reasonable setting) would feel demoralizing because the setting scale was so vast.
The new scale marks a “100%” point at about where I would put it for high quality if you’re just sitting on GPU power (e.g. small screen, nice GPU). You might still want to turn it down for performance reasons. The range from 100%-150% is highly experimental land…if you want to turn it up to eleven, we’re not going to stop you.
WorldEditor Developer Preview
There is now a binary build of WED 1.2 (download here). This is a developer preview: WED is still in environment and doesn’t meet the criteria for beta software. Basically: do feel free to poke around with it, but don’t use it on your real work. Don’t edit your scenery packs with it – make a copy first. WED 1.2 has not been tested enough to use for production yet!
The main feature of interest is ATC taxiway editing: WED 1.2 contains complete support for taxiway networks, as well as “flow” information to control the direction of operations. A number of weird ATC bugs actually stem from the automatically generated taxi layouts that X-Plane produces when the apt.dat layout contains no taxi information. By providing a custom layout, you can get the AI planes to behave quite a bit better.
* We periodically re-burn the disc 1 master to put the latest sim on it whenever we are preparing new DVD inventory. If you have an old DVD, please do not panic! Once the updater is run, the sim looks the same no matter which DVD you have.