Category: Air Traffic Control

ATC Taxi Layouts

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.

Posted in Air Traffic Control, Development by | 51 Comments

Notes about the ATC system

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.

  1. “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.
  2. “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.
  3. “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.
  4. “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.
  5. “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.
  6. “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.
  7. “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.
  8. “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.
  9. “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.

Posted in Air Traffic Control, Development by | 106 Comments

ATC: Description of a System Pt 1

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.

I keeeeed!

Posted in Air Traffic Control by | 115 Comments

Mommy where do baby airplanes come from?

“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)

Posted in Air Traffic Control, Blooper Reel by | 42 Comments

ATC And Airports – Where Does All of the Data Go?

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:

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

Posted in Air Traffic Control, File Formats, Scenery by | 26 Comments

New Scenery Tools: WorldEditor 1.1 Beta 3

Edit: the original post listed the version as 2.0 – the new WED beta is 1.1, MeshTool is 2.0, and my brain doesn’t work in this heat.

More scenery tools: I have posted a new beta for WorldEditor 1.1:

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.

Posted in Air Traffic Control, Development, Scenery, Tools by | 28 Comments

Some ATC Bloopers…(Free Willy!)

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.

Posted in Air Traffic Control, Blooper Reel by | 8 Comments

Time Lapse Takeoffs

I wasn’t going to post this video, but…what the heck.  So first, Chris sent me a link to this video a while ago.  Since Chris and I are both ATC nerds who used to work the Boston region on VATSIM a gajillion years ago, we thought it was pretty cool.

So when Robin stopped by the other day and I was showing him the in-progress ATC system (and to everyone’s surprise it didn’t just crash despite being under heavy construction that day) I made this video.

Like the other ATC video, this is taken with X-Plane 10 using version 9 airplanes and George Grimshaw’s custom KBOS v2 (I think this is the official convert that’s posted to

We’ll probably make a better version of this video once the system is further along; on the day that I took the video, incoming AI traffic was disabled due to work on the code, hence you see a lot of planes leave on 22R, but no one ever lands on 27.  This is life with in-development version 10; we all have our pieces of code work on and on any given day, someone else’s area might be under construction.

(BTW, we’ve moved the old video to YouTube.  As much as I get secret enjoyment from forcing everyone to download a QuickTime H264 video that won’t play on some browsers, we like having YouTube provide our bandwidth for free a lot better.  Click the graph to see the main website spike when we started hosting our own video.)

Posted in Air Traffic Control by | 19 Comments

V10 Release Date Mania

First, let me say that this post represents my opinions and my thoughts and does not reflect the official view of Laminar Research.

I’ll be the first to admit that the news and events that have “leaked” out regarding v10’s release date have created quite a bit of confusion, controversy and general discomfort amongst you guys; our fans/customers etc. I’m sorry to see the drama unfold in this manner. It’s certainly not intentional, it’s not a sign of v10 being delayed further and it’s certainly not a sign of v10 being canceled.

As i’ve said a dozen times already, v10 is very much alive and kicking. It consumes about 99% of all of our (the staff) time. It’s our #1 priority, it will remain our #1 priority and it has been for a long long time. There are many factors that contributed to the original delay of v10. I’m not going to go into internal details but I feel that it’s going to be a better product as a result. We’re not slacking off here. I don’t think there’s a single LR employee who’s put in anything less than a 40 hour work week in the past 3 years. I actually think the average is quite a bit higher and has been for some time.

One of the reasons for this tech blog is to give those of you interested an inside view into what it takes to write a flight simulator. It’s no simple task. In fact, in some ways it is rocket science!

I’m amazed by the amount of attention to detail that goes into XPlane’s development. Just as a quick example, I was  recently working on some ATC code and wanted to get a list of the runways at a given airport that had full ILS approaches. I was expecting there to be some kind of database lookup in the simulator that would say “oh runways 06 and 33 have full ILS approaches”. That’s a pretty basic assumption. “It’ll take 2 seconds to wire up” I thought….but that’s not how it works. There is no magical database for ILS approaches. XPlane doesn’t know about approaches directly, it knows about antenna types and location, OBS and glide slope angles. What I mean is, the database says “there’s a localizer antenna facing 036 degrees magnetic at lat/lon x/y and there’s a glide slope at x/y with a 3.5 degree angle.” This made my job a little more difficult because i needed to then compute the geometry of the localizer, glideslope and runways to determine what runway would benefit from a signal in that direction (don’t forget about parallel runways!). That kind of realism is unparalleled. What it means is that if a localizer antenna is offset at an airport because of obstructions (like runway 15R at Boston), XPlane will model the approach angle perfectly just like in the real world and you’ll come in at a slight offset. This is not new, the sim’s always been like this but it’s a new discovery for me. I guess my point is, sometimes even tasks that seem simple on the surface can be a bit more time consuming because we care about realism and the world is not a simple thing to model accurately…and that’s why this blog exists. We like to share with our users how COOL all of this stuff can be.

Getting back on track here, this blog gives you guys an inside look into our world so you have some insight into what kind of moving parts are in there. Our conscious decision to open this kind of dialog with our fan-base is a great thing, but it also can sometimes lead to miscommunications. Sometimes, we might say something in an innocent manner and you might take it out of context and misinterpret what we meant. For that, I’m sorry and we’ll take the blame.

With that said, I must ask and beg and plea that we all think twice before jumping to conclusions, trying to read between the lines and make inferences from quick unofficial statements made in a forum, a blog, facebook etc. Please do not assume that if a 3rd party vendor makes their own prediction of when v10 will ship, that it’s evidence of an official ship date. Please do not assume that if Austin himself says “by the end of the year” that he literally means “the end of the year.” If it shipped tomorrow, that would technically also qualify as “by the end of the year”. And NO, it’s not shipping tomorrow either. I can’t say that I blame people for wanting to hang on our every word and analyze our statements down to the verbiage but as much as I understand it, please try not to continue doing it. Official news, announcement of official features and official dates will be clearly marked as official. You will not need to read between any lines or make any assumptions.

So if v10’s not necessarily shipping in August and if “by the end of the year” does not necessarily mean “the end of the year”, then when is it shipping? The answer is….I don’t know! And that’s why there hasn’t been any official news yet. We’re not thinking about official dates yet because the date is arbitrary to most of us. When we’re all done with the core features and when it seems stable, then it will be released.

And because every post is better with a picture….Here’s a quick visualization of the math behind computing some ILS antenna intersections. The green line represents the localizer antenna beam. It starts in the background at the localizer antenna’s location and extends outward at the “OBS” heading of the antenna (note that in this unusual case, the localizer is NOT down the centerline of the runway!). The blue line starts at the glide slope antenna and extends outward at some angle above the earth’s surface. Typically this angle is about 3 degrees. The red line just represents the runway end. The point of this visualization is to see if you were perfectly aligned with the localizer AND the glideslope when you crossed the runway, where would you be? The intersection of these three planes is that pink dot.

Posted in Air Traffic Control, Development by | 41 Comments

The world is under control…

So as Ben has mentioned, I’ve been working on giving X-Plane a new ATC system. To be clear, the task was not to add features or fix bugs with the existing system, it was to write a whole new one…from the ground up. Why? Because our goal is to lay the foundation for a system that can grow over time; a system that we can easily expand and add features to. So what does this mean? It means that starting with the initial release of v10, the ATC system will grow incrementally until we feel it suits the needs of most of our users. It will never be a replacement for VATSIM however!

There’s only so much that can be done with artificial intelligence and since starting this project I’ve learned that humans make decisions in ways that are really really difficult to quantify, so lines have to be drawn somewhere. If you want that human factor, that’s what VATSIM’s for. The goal for our ATC is to make it as realistic as possible within the confines of what’s reasonable. It also needs to cater to a wide range of users. Some who are real pilots and do not deviate from ATC commands at all while others are new to aviation and may make some mistakes (even some dangerous ones). In real life making some mistakes will get you killed or at least earn you a phone call to the FAA…in here, the controller may grumble that you’re not listening and encourage you to follow directions again. I know that some of you are thinking “Why not just add levels of realism that the user can pick from a menu” and we may just do that for some things in the future, but for now I can’t stress enough that the goal is to be reasonable and flexible in our system design so that we can grow the system over time…all while keeping it fun for all types of users.

Enough blabber, time for some pretty pictures. The shot below is a picture of X-Plane with the North American ARTCC/FIR boundaries turned on. This is just for development purposes but it’s kind of neat to see the boundaries overlayed on the planet. As you fly from one center to the next, you’ll get handoffs from facility to facility.

And the shot below is what happens when I turn on the boundaries of towered airports. Any airport in the apt.dat file that has some combination of Delivery/Ground/Tower specified in it will be given a living control tower.

This only covers a tiny bit about the ATC system which is quite complex even in its infancy but I’ll do my best to keep the posts coming so that you can learn more about what it’s capable of.

I don’t have time to go into great detail about subsystems just yet (that’ll be covered in other posts) but I’ll leave you with a juicy detail….See those dots in the first image in the ZBW (Boston) ARTCC’s boundary? That’s a custom ATC pack (similar to a custom scenery pack) that I created that perfectly replicates Boston (KBOS) and Bradley (KBDL) TRACON airspace. Yeap, that means you can customize the system how you want it. More on what that means in the future….

Posted in Air Traffic Control, Development by | 11 Comments