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.
One of the major components of the new ATC system in X-Plane v10 are the taxi layouts. We sometimes internally refer to this as the “taxi network” because what it’s REALLY comprised of is a network of taxi segments attached to other segments at taxi nodes. The concept is pretty simple, a node connects two or more segments together and it’s a place where a decision could be made by the ATC system in order to change directions. Every single land-based towered airport in the world has it’s own taxi network.
To give you an idea of what a network looks like, here’s one for Seattle (click to see it clearer)
White segments are runways, green-ish (my wife would say “seafoam”) segments are taxiways, red segments are taxiways inside of an active-zone* and the white dots are the nodes. For ground operations, this is what ATC knows about and it’s the ONLY thing ATC knows about. It doesn’t know about buildings or obstacles in the way, it only knows about the pavement. Anytime ATC wants you to get from one point to another, it has to give you a routing composed of a connected list of these segments. The only exceptions are the start and end segments. ATC is only allowed to go “off the grid” to get you onto or off of the network. So if you’re at a gate and you request a taxi to runway 34L, it first tries to figure out the fastest way to get you onto the network. It does this by calculating whether you’re closest to a node or a segment on the network, choosing the closest one and then giving you a straight line to that point. Now you’re on the network. The opposite happens for end points.
So that’s how you get in and out of the network, but what happens along the way? It’s not all that different than the GPS in your car. ATC analyzes essentially every possible routing from your start/end nodes and chooses the one with the lowest cost. Note that I said lowest cost, not shortest distance. Think about the best way to get to work in the morning. Do you take all back roads? Do you maximize highways? Do you avoid tolls? Your decisions are based on far more criteria than the mere distance. The ATC system is no different. Distance is just one of the contributing factors that goes into it’s cost calculations.
Some (but not all) of the other things in the costs are segment type, segment usage, segment angle and the aircraft’s mode of operation. These can be fairly complicated so I’ll summarize them quickly. Segment’s have different types. They can be one way or two way just like streets in a city. Obviously the cost of using a one way street depends entirely on the direction you want to go. If you want to go the legal direction, the cost is nothing out of the ordinary. If you want to go the wrong way, the cost is REALLY high. In other words…only do it if you have no other options! The final segment type is “runway”. ATC tends to avoid taxiing you on the runways because that’d be terrible for airport efficiency…especially if the runway is an active runway. Another contributor to cost is whether or not the segment is already marked to be used. In other words, if another aircraft is taxiing southbound on a particular segment and you want to taxi northbound, that’s a potential problem, so the cost is high. If you’re going in the same direction, it’s no big deal. Segment angle is important as well. ATC does it’s best not to issue routings that result in steep taxi angles. 747’s have trouble making 150 degree turns for instance. Lastly, there’s your mode of operation. Remember how I said ATC hates using runways for taxi purposes? There’s an exception. When you land, it’s often beneficial to continue taxiing on the runway since you’re already on it and you’re already going quite fast. All of these factors contribute to the cost weighting and the route chosen for you is the one with the lowest cost at the time.
So where do these networks come from? Where does the metadata come from? Well, there are thousands of airports in the world that need these taxi networks so that ATC can provide service. It was important to us that ATC would function at any airport out of the box so Ben wrote some insanely cool algorithm that runs “on-the-fly” when you load up an airport. The algorithm looks at the pavement, erodes it inward leaving the “average” center points of all of the edges. This works pretty well but it’s not without it’s problems. The first problem is that it has no clue what the pavement is to be used for. Is it an apron? Is it a taxiway? Is it an access road? Is it a shoulder on a runway? Pavement is generic in X-Plane so there’s no way to know. The result, as you can see in the screenshot above, is that sometimes you get routings on small access roads. Another problem is algorithmic “noise” that’s causes the taxi lines to be quite zig-zagged and wavy. This is why the AI planes often look drunk when they’re taxiing. Often, the segments are not “reduced” or “smoothed” as much as we’d like. You can see the entrances to each runway tend to have a “Y” shape to them because of the “fillet” on the taxiway. This is a byproduct of the erosion code. There is code in there to reduce it as much as possible and “snap” the edges to the runway but it has to be generic enough to work reasonably well at thousands of different airports. Most of the time it causes no problems but there are cases where the “Y” becomes extremely wide because the runway has a thick shoulder created with a strip of pavement. One final problem is the lack of metadata. The active-zones are stamped out around the runways proportional to their size so seldom do they line up with any painted hold-short lines. We have no clue what the taxiways are named. I know what you’re thinking “Why not use the painted taxi markings and signs to aid in the algorithm’s decision making”. That was actually one of the first things we tried and found the data to be too sporadic to be useful and it made the algorithm very slow and complicated.
So if the algorithm has so many problems, why are we using it? Two reasons. First, the alternative is that no airports would have ATC capabilities on the ground until a user made a custom layout by hand. Second, the algorithm was created to be a stop-gap solution, not a substitute for human data! The REAL taxi networks need to come from a human! Once they are made, they’ll be added to the apt.dat and distributed with the sim moving forward. This means that over time, human data will replace the algorithm’s data and taxiing will get better. The taxi network generation is one of the major features of WED v1.2 which will be released in the coming weeks. Authors can create a network for their airports relatively easily. In my first time using WED, it took me only 2-3 hours to create the network and I’m completely clumsy using any kind of CAD type software. Someone who knows what they’re doing could do an equally complex airport in about an hour I would guess.
The layout in the first screenshot above is an autogenerated one. That’s NOT what you’ll be using if you go to KSEA in the simulator and that’s because I made a custom layout. If the sim sees a custom layout, it always prefers to use that. Here’s what my custom layout looks like.
So you’ll notice the lines are straight! There are no taxi segments through buildings anymore, there are no taxi segments on the access roads, there are no “Y” branches at the runway entrances/exits. Also, not visible from this height, the segments are lined up perfectly with the taxi paint and the active-zones perfectly coincide with the hold-short markings as well. I’ve also named each segment properly so that ATC can tell you exactly how to get to your destination e.g. “Taxi via Alpha Charlie Two Foxtrot Delta”.
There really is no substitute for human data. It definitely results in a much more realistic and far less problematic experience.
*An active zone is a taxi segment that’s protected by ATC because it’s adjacent to or in some way affected by an active runway. This is how ATC knows what to protect with hold-shorts and it’s also how ATC knows when it’s time to talk to Ground vs. Tower.
Many of you have taken the time to tinker around with the new ATC system. Many of you have had a good experience, others have found yourselves frustrated for various reasons. My goal here is to try and explain what you can expect from the system moving forward and describe the causes of some of the troubles that you might be having.
First, as I’ve said before, what you see in the ATC system is just the tip of the iceberg. The features are going to expand moving forward. What you are looking at now is not the way the final system will work. If we waited months or even years before shipping X-Plane 10, I’d still be saying the same thing. The reason is that the ATC system has the potential to be very large and very comprehensive much like the scenery system. It will evolve over time. There will never be a lack of new things that would be cool to have, there will never be a lack of things that can be changed for added realism etc. We have to develop things in stages however and what you see is merely the first stage.
The first stage was designed with one goal in mind: to create a system that’s comprehensive enough to give AI aircraft a purpose. Having AI aircraft buzzing around creates a living airport environment. Coupled with Ben’s new roads and railways, the X-Plane world is no longer a static world, it’s one that’s alive! AI aircraft are very low maintenance. They don’t have many requests, they aren’t picky about their routings. They just want to depart from one airport and arrive safely at another airport and the current ATC does that just fine. We’ve also allowed YOU the user to interact with ATC at this point but humans are not as simple as the AI planes. Your goals are a lot more specific and detailed than the AI goals and the current ATC doesn’t handle that so well. That’s coming! That’s phase two however. Right now, your interaction with ATC allows you to “get into the system” so that you can have a turn to use the runway for takeoffs or landings.
For those of you unfamiliar with the real world ATC system, let me tell you what it’s NOT. It’s not a turn-by-turn Garmin navigation system. ATC’s job is never to be your navigator or co-pilot. Yes, they often do assist pilots but this is NOT their primary goal. Their primary goal is the separation of aircraft within their airspace. Often, when ATC is assigning you headings for vectors, it’s because it’s easier for them to put you exactly where they want you to be than it is to let you fly however you feel. They’re controlling your position for spacing, for sequencing and for efficiency. This typically only happens on approaches where numerous aircraft are all converging in tight spaces to use a single runway.
X-Plane is no different. If you file a flight plan with a blank route, you’re expected to go DIRECT to your destination. You will not be given instructions on how to do that. If you file a route, you’re expected to fly the route by yourself. You will not be told when to turn or how to get from fix to fix.
ATC is also not a weather service. If you want to know the weather, you have to tune to the various AWOS/ASOS/ATIS frequencies around the world. These were in v9 and they still exist today. Yes it’s true that real controllers will often give you weather information if you ask. We may add a little bit of that in the future but even in the real world, it’s not their job…they do it because they like to be helpful people.
The first stage of ATC right now will give you an IFR clearance after you file your plan. They will assign you a squawk code for radar tracking. They will issue you a routing to your assigned runway. They will ensure that you are only allowed to depart when it’s safe. They will stay with you until you’re near your arrival airport. They will provide vectors to your approach (visual/ILS) and then they will issue you a landing clearance and allow you to continue as long as the runway is safe to use. If the runway becomes unsafe, they will instruct you to go around for another attempt. When you land, they will issue an appropriate taxi route back to your gate. That is the extent of what is possible with the first stage. It’s not comprehensive but it’s a foundation to work off of.
What kinds of things might you expect in the next stage? (NOTE: these are not promises. The details of future features have not been finalized but i’m trying to offer an idea of roughly where we’re headed). VFR operations. Requesting higher/lower altitudes in flight. In-air conflict prevention and resolution. Changing destinations in flight. Requesting specific runways. Requesting specific approaches…etc. etc. Please do not make feature requests at this time. I’m just rattling off some ideas from memory.
I have one or two remaining stability issues to clear up before I can fix some of the current usability issues that seem to have come up. For now, here’s an explanation of some of the issues so that you may at least understand what’s going on under the hood. I will say, the current system is a lot like a fire alarm in that it only takes one simple problem like a dying battery to be REALLY annoying. But like a dying battery, a relatively simple fix can make the problem disappear.
“I filed a FP but ATC isn’t talking to me” – That’s because you haven’t asked for anything. Tune your COM1 radio to the appropriate controller for an IFR clearance. At big airports, this is the Clearance Delivery controller. At smaller airports, this can be Ground or Tower.
“How do i know what frequency to be on?” – You really only need to know the frequency for two people. The guy who’s going to give you your IFR clearance, and the ground controller. After that, you will be instructed by ATC which frequency you should be on for the remained of you flight. You can get the DEL/GND frequencies from a variety of places. First, in the sim you can go to the local map view, enable Airports and then click on the airport that you want the frequency of. Then look at the popup. You can also use real world charts or resources.
“ATC is giving me a routing that’s through gates and buildings” – This is because the taxi layouts are auto-generated and have no idea where the buildings are. In the future, airport authors will create detailed taxi layouts that will completely alleviate this problem at their airports.
“I taxi to the runway and nothing happens” – If you were talking to ground, he should have handed you off to tower. If he didn’t, then perhaps you didn’t pull up enough. Make sure to taxi to the very end of the yellow arrows…not necessarily the hold short lines pained on the ground. Again, when human authors make taxi layouts, these should align perfectly (as they do in KSEA) but for autogenerated layouts, they may not. Trust the arrows, not the paint.
“I contact tower holding short of the runway but i don’t get a takeoff clearance” – This is because it’s not safe for you to takeoff. You have to be patient and wait. There could be someone taxiing on the other end of the runway, there may be an arrival that’s too close, or the last departure may still be in the way.
“I’m constantly being told I’m off course” – This is because you are… The problem however is probably not your fault. If you don’t file a route and you leave the routing blank, ATC assumes you’re going “direct”…the current bug is that direct is from the center of the departure airport to the center of your arrival airport. So what happens is that you takeoff, you fly runway heading, you get yourself adjusted, clean up the aircraft….by this time, you can be MILES from the center of the airport where the route line began. Now you decide to “proceed direct” your destination but you’re now paralleling the course that ATC expected you to fly. The real solution to this in the future is me fixing this in various ways but for now, try to fly a course track that emanates from the center of the airport or file a real routing. Real routings may sometimes have the same issues for the same reasons but will be probably be less severe.
“I’m constantly hearing AI planes getting yelled at for their altitudes” – yeah this is because some of the AI planes are being asked to climb to FL360 or so and they seem to be climbing in an inefficient manner. They end up running out of airspeed at FL330 or so and then are not smart enough to step climb up the rest of the way so they just stay there on a border-line stall. Austin will need to tweak the AI planes in the future.
“ATC’s not talking to me after I depart” – Why should he talk to you? You’re the pilot, your job is to fly the plane the way you filed. ATC is NOT a turn-by-turn GPS. You need to know how to get to where you’re going on your own and you are expected to do so. The ONLY time you can expect vectors currently is when you get within 30nm of your arrival airport. At that time, ATC will issue you vectors for your visual or ILS approach.
“ATC forgot about me after issuing me some vectors” / “ATC is vectoring me away from the airport” – Perhaps ATC is not issuing the tightest vectors in the world if you’re in a small GA plane, but it’s not THAT far off. ATC (much like in the real world) typically issues vectors to final using a vectoring Tee (See below). Yes, you may be told to fly away from the airport. Yes he may give you headings that seem out of the way. He will not forget about you. Hang in there. Depending on your arrival angle, you may be given some shortcuts. In the future, I can add some tighter shortcuts as well but it’s actually not that far off. I think in it’s worst case, you can expect an 8nm intercept to final.
So here’s a vectoring tee like the one used by X-Plane’s ATC. The numbers represent the headings you could expect for this sample runway (09/27). Depending on whether you’re approaching from the north or the south, you’ll be given only half of this Tee. Let’s pretend that you were south of the airport…you’d be given a right turn heading 090, then a left turn heading 360, then a left turn heading 330, then finally a turn to 270. Depending on your aircraft type, you may be required to fly away from the airport by several miles. This is normal. ATC has not forgotten about you. You will be turned back toward the airport when the time is right.
So that’s a quick dump of my brain regarding ATC at the moment. There will be more posts in the future about future features and what you can expect. The purpose of this post was to just give you a glimpse of the status of things and alleviate some confusion all around since it’s a completely new paradigm for many people.
I’ve always been into photography as just one of my many expensive hobbies. A very respected Photographer Jerry Ghionis always says “You don’t have to be the best, you just have to be better than last week.” I’ve tried to keep that in my head while working on the ATC system because like you, I too want it to be the best…and that’s the long-term goal, but I have to be honest, the ATC system in X-Plane v10.0 is not perfect. There, I said it! The ATC system is a tough thing to model not just because of its complexity but also because humans are inconsistent and unpredictable. Humans add a touch of randomness to every decision from the simplest thing such as phraseology to the most elaborate thing like vectors for an instrument approach.
What I can say however is that it’s a system that’s designed to get better. Until now, the ATC system has been very stagnant with little improvement or change in many versions. I’ve completely started from scratch and come up with a system that can be built off of so that it gets better and better. If you think you have a list of requested features, I’m willing to bet that my list is longer. Like the scenery system and many other systems in X-Plane, there’s ALWAYS something that can be done to make things better.
Another thing to consider that may not be obvious to a lot of people. The ATC system is really two pieces in one. Of course, there’s air traffic control to give you instructions but more importantly (I’d argue) is the AI traffic. Before, AI aircraft just flew around doing whatever they felt like…almost like zombies. Now however, ATC has control of them. That means they play nice, it means they follow you around to some extent so that the world is alive wherever you go. It may not seem like much but when you turn the AI traffic off, you’ll feel very alone. My point is, airports now FEEL like airports. Even if you decide never to use the ATC system directly, just having the hustle and bustle of a busy airport is a win. Before anyone asks, yes the system is currently limited to 20 AI aircraft. The aircraft are on their own threads so those of you with multi-core processors will certainly rejoice in seeing that things are using those other cores. In the future, we do plan on having alternate ways of getting the traffic count up higher for really busy airspace but I’m not willing to discuss that just yet.
So what can you expect from the INITIAL release? AI planes will be around you. They’ll be on the field departing and arriving with you. As you depart and fly around, they’ll transition to pass by you enroute. You’ll hear/see them on text and voice and even out the window. AI planes run REAL physics so you’ll see controls deflecting, flaps moving etc. As a human, you can file a flight plan, grab a clearance, get taxi instructions, get a takeoff clearance, you’ll transition to Departure or Center. They’ll issue step descents and vector you in to an ILS or visual approach at your destination.
We also have designed in a lot of customization in the traditional X-Plane fashion. You can customize the voice and text phraseology. You can (and should) come up with your own airport taxi layouts. Insert hold short points, tag the taxiways with the real names, create your own runway flows and of course customize controller airspace and frequencies.
A note on runway flow which i think is really neat….You specify which runways get used for different operations based on wind, ceiling, visibility, time of day, initial heading after departure and aircraft type. This lets you model how the real airport functions under various conditions not just for realism but also for efficiency (which is why the real world does it that way to begin with).
There are a lot of features still left to add but I hope you’ll understand that it’s a brand new system in its infancy. I hope you can see that our goal is to continuously add features and improve it incrementally…and also do this while offering users ways to customize the experience. What you see in v10.0 is NOT the end of ATC development. It’s just the very beginning.
Finally, please do NOT ask “Will we have feature X?” or similar variations. I do not want the blog to become a center for feature requests…especially on a system such as ATC that’s just been born.
“Well little Johnny, when a KC-10 and a 747 love each other very much…”
On a more serious (kinda) note, this is a shot of what happens when ATC fails at spacing its aircraft properly. These two planes flew all the way down the ILS like this which is obviously a bug…but fun to have a chuckle about as well. If you look off into the distance, you can see some other aircraft, also on the ILS lined up against the golden sky…very dramatic!
(Notes: This is v9 scenery, v9 planes, a slow debug build…nothing special here)
This post is going to be a bit of a brain dump: I will explain where the various new types of data go for the new airports and ATC system.
First: everything lives in scenery packs. Since X-Plane 9, every bit of scenery X-Plane has (including the default airports, global scenery, and art assets for taxiways) all live in scenery packs. Those scenery packs live in Custom Scenery (if installed by user) or Resources/default scenery (if installed with the sim). The global scenery packs have their own folder in the main X-Plane folder so you can find them easily – at 78 GB it’s likely you might need to delete some, then reinstall later.
A scenery pack in version 9 can contain the following “stuff”:
DSFs – that is, scenery tiles for 1×1 degree areas of the world. Those DSFs can contain a base mesh or just overlay 3-d on top of another base mesh.
Art assets (.obj, .fac, .png, etc.) in any sub folders desired.
apt.dat – an apt.dat file can provide replacement airport layouts on a per-airport basis. You can replace one or all of the airports.
library.txt – a scenery pack can publish its art assets to the library for use by other scenery packs.
In X-Plane 9 we ship a scenery pack with most of our airport art assets (published to the library) and we ship another scenery pack containing Robin’s latest data – we try to update this scenery pack in each patch to match Robin’s latest.
In X-Plane 10, scenery packs are still the way you get your data into the sim. In fact, all ATC data sits inside a scenery pack too. We figure that you might want to make a custom airport with custom ATC, custom airport layout, and custom buildings. So rather than reinvent the wheel, ATC data is part of scenery data. The ATC data shows up in a few places:
Airport ground operations data actually live in the apt.dat file. This includes “flow” information (e.g. which runways are in use, what’s the pattern runway) for various operations as well as the ground taxiway layout. The ground taxiway layout specifies a connected line graph of where airplanes can taxi. (Note that there is only one taxi layout even if there are multiple flows. This is because even if the runway in use changes, the concrete doesn’t move.)
Airport controller and airspace specifications (including tower controllers) live in a new atc.dat file – you can put one in each scenery pack, not unlike the apt.dat file.
Voice packs are created using a .voc file and a pile of sound files. Like OBJs, they can be put into the library – voice packs are the “art assets” of ATC.
Why is it that the ground layout is in the apt.dat file but the controllers are not? Robin collects the apt.dat file, and we wanted to make sure that if someone moves the pavement, that person moves the taxi layout too. Having them in separate files would be a recipe for a loss of synchronization.
Note that there is no mention of airport buildings in any of this. Airport building locations will ship as DSF overlays – they’re a scenery pack just like we have in version 9. The default art assets made by Tom will also live in a scenery pack and be exported to the library for anyone to use.
Since everything is implemented via scenery packs, you can create anything we can create, and you can publish your work directly via a custom scenery pack. You don’t have to share your data with any of the central collection-and-databasing efforts to use this new technology.
There will be two types of scenery packs that ship with X-Plane (and are updated via free patches during the lifetime of the sim).
First, we have default art assets that we provide to make the sim work and to help you create scenery.
Default airport elements, including the airport building lego brick library.
Default ATC voice packs.
Then we have scenery packs that come from collected data. We ship the latest updates.
Default airport file from Robin, containing airport pavement layouts, gate positions, and (in v10) taxiway diagrams and runway flow information.
Default airport building placements (in DSF form). We will start this file off but then it will become something that everyone can contribute to and use.
Default ATC controller file, containing airspace information and controllers/frequencies. We will seed this file with center controllers to cover a big chunk of the world, but I am hoping that we can accept user-submitted corrections and contributions.
(If you squint at this list, you’ll see the divide: we are trying to involve the entire community in data-gathering activities, but we are having our internal art team make the default art assets.)
Finally, there is one more piece to the puzzle: autogen. Autogen is a horribly ambiguous world in flight simulation because it means 85 different things. So let’s be more specific: automatic in-sim generation of data. When the sim is missing data, what data will X-Plane “make up” on the fly? There are two cases of automatic data generation in the sim while you fly in version 10:
If there is no controller specified in any scenery pack for a given airport, but there is a tower/ground/delivery frequency for the airport, Chris’s ATC engine will automatically create a controller based on the frequency. This means you get tower/ground/delivery ATC on the right frequencies for all of the towered airports, even if we don’t put those controllers in the default controller file.
If there is no airport layout for a towered airport, we will generate a taxi layout and default flows by picking runways and analyzing the taxiway structure. This allows you to have AI ATC at any towered airport. (The layouts that X-Plane generates are not going to be as good as what you can build in WED.)
We almost always prefer pre-generation of data to in-sim generation – it lets us use a higher quality algorithm without hurting fps. (One of the limits of the ATC layout generation algoirthm is that it can’t use too much memory since it is running inside X-Plane.) But in the case of airport controllers and layouts, a custom scenery pack can contain an airport that we’ve never seen before – so we have to be able to generate the matched ATC data on the fly.
Like previous betas, this build mostly fixes bugs around import and export, which was the area that caused the most trouble. Please file WED bugs via the scenery tools bug base; I don’t often get to work on WED, but when I do, I can kill off a bunch of bugs at once if there are good reports. Thanks to all of the users who have submitted good bug reports with example scenery packs to help reproduce the problems.
Future WED Versions
Simultaneous to bug fixing on the WED beta, we are adding new features to support X-Plane 10 ATC: WED will be the tool you use to edit taxiway routing diagrams and airport layout flow information for an airport. (This means that you’ll have your physical pavement, your routings, and your custom scenery all in one environment.)
These features are disabled in the WED 1.1 betas, but once version 10 is released and WED 1.1 is final, we should be able to rapidly go to beta on the new features; since we use WED to build our test layouts now, it should be in reasonably good shape.
In the long term, I’d like to see WED provide a visual front-end for MeshTool*, but I won’t let this hold up a release of an ATC-ready WED; so far having “future features” floating around in the code (disabled for release) hasn’t caused any bug reports or stability problems for the existing 1.1 beta candidates.
WED also needs a file format change; my original decision to use an sqlite3 database was the wrong one; when the file format change happens, there will be full backward compatibility for reading old projects, so you’ll be able to bring your old projects forward just by opening them; you won’t have to reimport the DSFs and you won’t lose your groups and other WED-specific information.
* There’s no reason why WED has to be the only front-end for MeshTool, and it may not even be the first one released. One option might be to make a MeshTool export script for qGIS.
In testing some ATC stuff today, I was curious why I saw smoke coming from the water on the left side of the runway. As I got closer, I found a KC-10 rising from the ground like a mighty Phoenix….struggling to get out of the controlling grips of Air Traffic Control. Ben said it reminds him of Free Willy.
And of course the usual disclaimer…the purpose of the video is to have a giggle at the AI plane’s bug…ignore the ugliness of the rest of the situation. The colored lines are used for debugging aircraft routing issued by ATC.
The problem however is probably not your fault. If you don’t file a route and you leave the routing blank, ATC assumes you’re going “direct”…the current bug is that direct is from the center of the departure airport to the center of your arrival airport. So what happens is that you takeoff, you fly runway heading, you get yourself adjusted, clean up the aircraft….by this time, you can be MILES from the center of the airport where the route line began. Now you decide to “proceed direct” your destination but you’re now paralleling the course that ATC expected you to fly. The real solution to this in the future is me fixing this in various ways but for now, try to fly a course track that emanates from the center of the airport or file a real routing. Real routings may sometimes have the same issues for the same reasons but will be probably be less severe.
