I’ve been meaning to write a post about the difference between general purpose flight simulators and AAA first person shooters for a while; a particular feature in X-Plane 10.04 brings some of these differences to light.
A typical high-end first person shooter is a closed game; the art content and the rendering engine ship together, and the art content is authored specifically for (or repurposed for) that particular rendering engine. The content is also completely available ahead of time; it can be authored without worrying about rendering engine changes or the addition of third party add-ons. Similarly if a rendering engine change requires revising all art content, this is at least possible, since all art assets live in house.
Compare this to a general purpose flight simulator. The rendering engine and art content may be revised on different schedules. The artists building third party content have limited access to the developers writing the rendering engine, and the rendering engine acts like more of a platform than a closed product.
Because X-Plane’s rendering engine is a platform, rather than part of a closed product, we try to keep optimization and performance work generic. When possible, we put in optimizations that act automatically without author participation. When we do have optimization advice, it tends to be generic advice that applies over a wide range of rendering engine revisions. (For example, using less OBJ ATTributes and atlasing many small textures into one big texture have been good advice for at least the last seven years.)
Sometimes, however, it becomes necessary to put in authoring features that are somewhat specific to the rendering engine and optimization. This is what has happened with cockpit pre-filling.
Before we go any further, you may want to read about pre-filling here. (One thing I am trying to do is to put the specific tutorials and documentation into permanent articles and not blog posts that are lost in the archives after a few months.) Basically when we pre-fill, we draw part of the airplane early on to mask out clouds, saving fill rate on the GPU, improving framerate.*
For the 2-d panel, we put in pre-fill in X-Plane; no artist intervention is needed. But for the 3-d cockpit, we can’t easily pre-fill without you setting some check-boxes on your airplanes.
The problem with the 3-d cockpit is that it is, in its entirety, rather expensive to draw. So we can’t just draw the entire 3-d airplane (for the purpose of masking clouds) or we’d be burning a possibly large amount of CPU to save a possibly large amount of fillrate. The right trade-off depends on the actual plane, and X-Plane can’t figure out automatically what the right thing to do is.
Hence the pre-fill check-box in X-Plane 10.04. With the pre-fill check box, you (the author) mark your content for optimization to hit the right balance of CPU and fill rate savings. (See the articles linked above for guidelines on how to set the flags sanely.)
Fortunately if the check boxes are set wrong, the worst thing you get is poor frame-rate (not crashing). But this is a rare case where third party authors can (and have to) input tuning data directly into X-Plane.
(And for concerned users: if an airplane doesn’t have the pre-fill check-boxes set up, the performance is the same as 10.03 – there’s no loss, this is just an opt-in optimization.)
* If you are asking at this point “why didn’t you guys do this years ago, you idiots?!?” the answer is: because it never mattered before. X-Plane 9 simply doesn’t use much fill rate, so it never made sense to spend CPU time to save fill rate.
X-Plane 10.04 is out for beta. A few notes:
To get 10.04, you must run the updater and check “get new betas as well as updates”. The updater will not get you a beta unless you specifically ask for it, and X-Plane won’t nag you to update if the patch is only in beta. (This is our preferred method of running betas, and all future betas will be like this.) There are some pretty major fixes to ATC and AI aircraft behavior, so it could be a beta worth getting.
We are starting to transition more of our various websites to WordPress; this is an on-going process. The eventual goal is to have all of our various web info into WordPress (on either the main site or the “developer”* site, which will grow out of this blog) and drop the wiki. MediaWiki makes everything possible when it comes to content management, but it makes nothing easy, and controlling spam has been a real problem. Eventually all of the knowledge-base articles that the sim can link to now will be browsable from those sites, but for now we’re still working on building up the infrastructure in our few free moments.
And speaking of developer resources: I am working on a release of scenery docs and updated tools; it’ll take a little bit to get everything together. I am getting hammered with requests; a complete release should get most people where they need to go, so I am trying not to jump in and write one-off emails answering questions; better to focus on permanent docs I think.
Finally, please don’t email to ask me “did you fix my bug yet.” If it’s not listed as fixed in the release notes, it’s not fixed. We’re trying to be accurate in the release notes so that you don’t have to ping us every single release, which burns your time and ours. Not all bugs will be fixed this beta; we have enough high priority ones that we’re going to get fixes out as quick as we can.
* The developer site will include aircraft, scenery, and ATC authoring info; the SDK website will remain separate, as LR doesn’t own the SDK IP. (It’s more like FSUIPC that way.)
X-Plane 10.03 is now final; here’s a little bit of what’s coming up:
- For a while we were “pushing” betas to all users via the auto-update system. We did this because we had critical crash fixes we wanted to get out quickly. Fortunately, that phase of the release is now over and 10.04 betas will only be available if you opt in and check the “beta” box in the updater.
- For 10.04 we are continuing to tune performance, fix bugs, improve the look of the sim, etc. In other words, it’s more stabilization and polish.
- Aerosoft has built a few custom and lego brick European airports for X-Plane 10; these will be available as part of the update for users who have scenery installed. This might be in 10.05 depending on how quickly I can get the installer/updater work done.
- Tom is working more with the airport lego brick library using WED 1.2; I fixed some WED bugs last week and will try to get some releases out soon.
I’ll post more on framerate in the next few days.
This is an authoring “gotcha” in X-Plane 10:
Do not use a degenerate UV map if you are using bump maps. If you use both techniques, your object will have black splotches in HDR mode.
Let me define what I mean:
A degenerate UV map is a UV map where the “U” and “V” axis (that is, the horizontal and vertical axes of your texture) are not moving in different directions across the face of a single triangle.
The most common case is when all three vertices of a triangle are mapped to a single point in the texture, giving you a “solid color” triangle (that is, the whole triangle picks up the color of the single point of the texture.
You can also have this problem if you use “1-dimensional” texturing – that is, all three texture points for a triangle are along a line in the UV map or two of the three points are colocated.
If you need to use bump maps for your OBJ and you need a “single color” spot, separate the UV map of each vertex of the triangle by a little bit (even just one pixel).
You’ll know you have this problem when you see some of your polygons show up as pure black when HDR lighting spills on them. Here the top of the APU/air conditioner on the jetway has a degenerate UV map. In HDR mode it shows as a black area despite the spill light. This kind of artifact will show through any geometry that should normally cover the affected area.
Why This Happens
(What follows is strictly for the computer graphics nerds – you don’t need to understand this to fix your OBJs).
For the computer graphics nerds: in order to apply a tangent space bump map, you need three basis vectors to create a 3-d space for the normal vectors; the tangent space bump map is then essentially a perturbation of the regular normal vector. (Or put another way, the tangent space coordinate space system defined by U, V, N is used to transform the tangent space bump map back into world space. For the degenerate case of no normal map, the normal map can be thought of as 0,0,1 and the transform is a no-op from what we would have had anyway.)
Some engines require that the U and V axes be specifically passed per vertex. X-Plane, however, reconstructs the U and V map from the UV map of the model. When the UV map of the model is degenerate (e.g. it doesn’t form distinct non-zero length basis vectors along the output triangle) the coordinate system of the tangent space normal map ends up degenerate and the output normals suffer from a divide-by-zero.
The divide-by-zero is burned into the G-Buffer and the artifacts are thus persistent.
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.
Fill rate: when we talk about fill rate, generally what we’re talking about is your GPU’s ability to fill in individual pixels to make the final image you see while flying. (The actual components of GPU throughput get a lot more complex, but we’ll keep things simple for now.) Two key things to note about fill rate:
- It only comes from your GPU – not your CPU.
- The bigger the size of X-Plane’s window (or the higher the full screen monitor res), the more of it you use.
Therefore I can offer this very simple test as to whether you are fill-rate limited:
If you are running in windowed mode and making the window smaller improves frame-rate, you are fill-rate limited.
(There is actually one important exception to the above test: if you are running out of VRAM, making the window smaller uses less VRAM for the main window + off-screen buffers, which can help fps. So be sure to see whether cutting your texture res helps fps – if it does, you are out of VRAM.)
Fill rate gets used up by:
- A larger rendering window. This is the number one consumer of fill-rate. Double the size of the window in each dimension, you use 4x the fill-rate. That adds up quick!!
- Clouds tend to be fill-rate intensive.
- HDR mode is significantly more fill-rate intensive than non-HDR mode.
- The 3-d cockpit is more fill-rate intensive than 2-d and external views, particularly with HDR enabled.
- Shadows, to a limited extent.
X-Plane 10 contains a stat called “cpu load” in the framerate output data line; I will describe its full meaning and implication in another blog post, but generally low CPU load (e.g. < 0.7) means you are fill-rate limited. If your CPU use for one core is 100% (this means 25% in the task manager for Windows users on a 4-core i5, but 100% in top for Mac/Linux users no matter what the number of cores) then you are almost certainly not fill-rate limited.
Optimizing Fill Rate
X-Plane 10.03r1 will post in a little bit – this is our first attempt to finalize X-Plane 10.03. It is not the end of the bug fix and performance tuning work for X-Plane 10. But if we can get a stable 10.03 we can use it as a baseline and limit betas to those who check the “get betas” check-box in the installer.
X-Plane 10.03r1 contains fill-rate optimizations for the 2-d and forward-no-HUD views; we’ll have to see how much they help people, but they should help you a bit if you are fill rate limited, flying a plane with a 2-d cockpit, and are seeing low fps with clouds and/or HDR.
Once 10.03 is final, we’ll start 10.04 and I will attempt to make a similar set of optimizations for the 3-d cockpit. Note that the 2-d optimizations do not apply if you have a plane that uses the 3-d cockpit for the 2-d view. (Since all of the new X-Plane 10 default planes do this, we’ll need the 3-d optimizations in 10.04 to see the performance benefit with the 747, Baron, and other new default planes. The Cessna, Cirrus Jet, and Piaggio from X-Plane 9 should all benefit immediately.)
Your Mobile GPU Is Light But Not Fast
Here is a table I culled from Wikipedia: it is a table of GPU performance for the “top end” cards for ATI’s last 4 generations of hardware.
| CARD |
DATE |
GP |
GT |
BW |
GFLOP |
| 4870 |
Jun 08 |
12 |
30 |
115 |
1200 |
| 6970M |
Jan 11 |
21 |
32 |
115 |
1305 |
| 5870 |
Sep 09 |
27 |
68 |
153 |
2720 |
| 6970 |
Dec 10 |
28 |
84 |
176 |
2703 |
| 7970 |
Jan 12 |
29 |
118 |
264 |
3789 |
GP = gigapixels/second of fill, GT = gigatexels/second of texture, BW = GB/second of memory bus bandwidht, and GFLOPS = gigaflops/second of MADD. At least I hope – see the original table.
Now I have inserted one mobile GPU (the 6970M) into this chart. So the first thing you can see is: the 6970M provides in a laptop the power that was available in a desktop about two years earlier, more or less. That’s a big step back in time.
The reason is simple: mobile GPUs are typically cut down in their core configuration – there’s no way you can run a 150W full power GPU with those 3 fans in a laptop.
If you have an iMac, you have a mobile GPU. Even the older iMacs which didn’t have the “M” designation on their chip, those were mobile too. In fact, you’ve got a mobile GPU on a huge screen. (Super-size to the 27″ iMac to get the 4x fill rate boost and you pick up 1.7x the pixels; if you get the big iMac with the cheap GPU you have a mid-range mobile GPU on a 2560 x 1440 screen!)
Some Kind Of Summary
I’m not entirely sure what my main point here is…perhaps the executive summary is:
- We (LR) are working to optimize fill rate in X-Plane 10. Fill rate is not the only performance bottleneck we are working on, but it is a very important one. Some of this is in X-Plane 10.03r1, some will come in later updates.
- You can determine whether you are fill-rate limited by resizing your window.
- If you have a mobile GPU in a laptop or iMac you may have less fill rate than you would expect.
At this point I am mostly done investigating weird video card behavior: these two pages are now reasonably accurate for X-Plane 10.
We are still trying to resolve as many of the known issues as we can, but now that we know what cards are in and out, it gives me more time to work on performance and scenery tools.
Happy New Year! I will try to get a few more posts out over the next few days; we spent a lot of December with our heads down trying to fix as many bugs as possible despite the chaos that the holidays always inflict on any company.
We had a slight fire-drill with beta 8 last night; it turns out it crashes on Windows, so we pulled back to beta 7. X-Plane 10.03 Beta 9 will come out today and fix the Windows crash and 1 or 2 other issues.
Right now we are “pushing” betas to everyone; this is not the norm and we will go back to the normal process (where users opt in to betas) once the 10.03 beta process completes. Since 10.03 has so many stability fixes, we want to make sure everyone gets them. We’ll lock 10.03 down before proceeding to additional performance tuning.
For December I had four things I was trying to work on: stability fixes, backward compatibility, performance enhancements, and third party support. I was only able to make progress on some fronts. At this point we have most of the hardware support issues stabilized and we’re close to closing up the crashes. (There is no short term fix for running the sim out of address space unfortunately.) We’ve done some performance tuning and a lot of analysis, but a lot of the work to act on the analysis is yet to happen.
The front where I made no progress is in third party support. So starting this week I am going to try to dedicate one day a week to some kind of third-party-only activity, whether it is getting out the docs on the new v10 authoring features, getting out scenery tools, etc. We have a lot of “almost ready things” and I don’t want to keep authors waiting.
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 had a chance to catch up with Robin the other day and discuss airports with him. Here’s the basic road map for airports in X-Plane 10.
In version 9, an airport consisted only of taxiway layout data. Robin collected and managed a big database of contributed airport taxiway layouts, which are available under GPL and ship with the sim. WED 1.0 lets you edit these layouts.
In X-plane 10 we now have three categories of airport data:
- The taxiway layout – this lives in the apt.dat file.
- The ATC taxi layout and flow information. This also lives in the apt.dat.*
- Lego brick building placements. This lives in an overlay DSF.
Our plan for the version 10 run is to collect all of this data together and redistribute it all, just like we do the current apt.dat file.
We also plan to build a few airport building layouts ourselves, using the existing lego bricks, without custom elements. This will help us further debug the bricks, get users some more airports quickly, and help us understand the authoring process. We have some of Tom’s time earmarked for this.
WED 1.2 will support taxi layouts and airport building placement. Based on my talk with Robin, I believe I will also need to build a more specialized “Send to Robin” export function that pre-checks and packs the submission to streamline the process; since an exported airport will include DSFs and apt.dat files (and should not contain custom OBJs) having the packing be automatic will save everyone a lot of time.
What about autogen buildings? I don’t know. We wanted to try this before we shipped and ran out of time. I think we could autogen buildings for small airports that just have buildings next to the autogen taxiways, but for custom layouts I don’t know that autogen will ever be good enough to make humans happy.
Over the next few weeks I’m hoping to have more time to roll out tools and documentation to move this process forward. The library is already complete, so the quicker we can get everyone using it, the better.
* If you have an airport layout wihtout taxi layout and flow information, X-Plane automatically generates default flows and layouts.
