Author: Chris Serio

X-Plane for Android is NOT Infected!

It has been brought to my attention that Android users that have Webroot’s Antivirus app for Android installed are getting false reports that X-Plane contains a trojan virus.

This is of course a complete false-positive on the part of the Anti-virus software. I’m doing my best to get ahold of Webroot’s developers to aid them in correcting their software. In the meantime, rest assured we’re not doing anything dirty to your android device.

Posted in Android by | Comments Off on X-Plane for Android is NOT Infected!

Slow “Open” Dialogs…If you’re a hoarder.

I’ve yet to see an episode of “Hoarders” with an aviation theme but apparently people with that flavor of the disease exist because I’ve gotten a chance to talk with a few who have accumulated a serious amount of 3rd party X-Plane content over the years. I’m joking of course and don’t mean to insult anyone or make light of people with illness. If you want to complain about my faux pax, contact Ben Supnik. 🙂

There is a real X-Plane issue here however. X-Plane makes no assumptions about the locations of certain types of files. Aircraft/Airfoils/Objects/Bitmaps etc are allowed to be…well pretty much anywhere in the X-Plane folder (with a few exceptions). You can argue this is silly but for historical reasons, that’s the way things are today. In order to show you a list of all aircraft for example, X-Plane has to search everywhere within its folder in order to find them all.

In prior versions, if you added a new aircraft into your Aircraft folder for example, you had to restart the sim for it to appear. As of X-Plane 10.10, X-Plane now scans for new files every time the “Open Dialog” is opened. This is done intentionally as many users have asked for this behavior. For 99% of the population, this works fine because X-Plane’s file system is relatively flat but if you’re a hoarder and you have a HUGE amount of content in your X-Plane folder, you may notice a delay when opening new Aircraft/Airfoils/Objects etc. This delay always existed but it used to ONLY happen during sim load so it was hidden.

The problem is that you have to rescan the entire file tree each time the dialog is opened. I know a lot of you developers are saying “No you don’t! You can hook the OS and look for changes since the last time and rely on your cache if there were no changes!” and you’re right…but you haven’t seen X-Plane’s File I/O code. You’ll have to trust me when I say it’s non-trivial to support this on 3 different operating systems and it will only benefit a very small percentage of users. This is not where our time needs to be spent at the moment.

In the meantime, we did want to provide a workaround but before I get into that, I want to explain things in a bit more detail. The slowness I found in the few cases that I studied were caused by 3rd party folders within X-Plane that did NOT contain any X-Plane relevant data. In other words, there were no aircraft, airfoils, objects, scenery etc in it that were being used by the sim. That means, the sim had to search through the whole thing only to find…nothing. One common folder was “Custom Scenery (disabled)” which is apparently created by a plugin out there that lets you disable certain scenery packs. This folder has now (As of 10.10R2) been added to our internal black-list so that we know to automatically skip it when searching for data. There are other folders that were already in the black-list. Here’s a current list:

  • Global Scenery*
  • Custom Scenery*
  • Resources
  • Plugins
  • Liveries
  • Cockpit
Note that the * is a wildcard so anything can appear after and still match our filter.

This is very important to note…the black-listed folders are automatically skipped by X-Plane for one purpose only…Dialog Population! Files in blacklisted folders will not appear in any “Open Dialogs”. Examples include Open Aircraft, Open Replay, Open Situation, Open Airfoil (planemaker) etc. Files in these black-listed folders can still be found by the sim for other purposes. Notice that custom scenery still loads even though it’s blacklisted, plugins still work properly etc.

What we wanted was a way for users to specify their own black-listed folders. Some users  are developers and have folder after folder of development data in the X-Plane tree that they’d want to blacklist. Starting in 10.10 R2, you can do this by creating a file called:

dont_search_here.txt

in the folder that you want to blacklist. The file can be blank…its contents are completely irrelevant as only the name matters. When X-Plane encounters a folder that contains that file, it will completely give up on the folder and not scan it or scan any deeper. So any Aircraft, Airfoils, Situations, Replays, Weapons, Objects, FMS files, Waves, FDR files or Bitmaps in there will not appear in the appropriate open dialogs.

My recommendations to you:

  1. Do your best to keep non-X-Plane specific data out of the X-Plane tree.
  2. If you can’t or don’t want to follow advice #1, that’s fine. If and ONLY if you suspect that your data is causing X-Plane’s various “Open Dialogs” to be slow, try dropping the dont_search_here.txt into the folder if it doesn’t contain any files you want displayed in X-Plane’s dialogs.
  3. If you’re not experiencing noticeable slowness, don’t mess with this at all! This is not a widespread problem!

 

Posted in Development by | 10 Comments

CSI: Joystick Edition

[Scene opens with a joystick being thrown across the room in frustration. Camera angle is from the ceiling looking down. A rotating and twisting view creates tension as it centers on the joystick, laying abandoned on its side as the dust settles. Cut away to a different angle. In the background is an iMac with Google Chrome open in the background just barely in focus.]
[In walks developer Chris Serio wearing a pair of Ray-Ban sunglasses. He nudges the joystick with his boot before crouching down and removing his sunglasses to get a closer look.]

Chris: “Looks like someone really had it out for this Joystick”
Ben: “Yeap…tossed it like a salad at Denny’s. What do you think ticked them off?”
Chris: “I bet Google’s behind this somehow…”
Ben: “Google? Really? I thought their motto was to do no harm?”
Chris: “On the contratry…They’re involved in everything!”
[Chris stands up and walks over to the computer…the camera zooms in as Google Chrome comes into focus on the screen]
Chris: “You see this? Chrome…that’s not a coincidence. I want the computer’s ip address…run it through CODIS. Bag it and tag it”
[The camera moves back and zooms out as Chris pulls his sunglasses from his pocket, placing them on his face as he pauses to speak]
Chris: “This Joystick killer’s about to get…..yoked”
[Cut to opening credits as The Who’s “Won’t Get Fooled Again” plays loudly]

Ok so perhaps I’ve seen too many episodes of CSI in my time…but sometimes I must say I do feel like more of a detective than a developer.

The latest weirdness with joysticks is that on Mac only, sometimes they do not seem to work at all. In the log, you’ll see an error message stating that the device could not be opened. I’ve seen it myself before and it’s odd because typically device access is shared between processes. Imagine if your keyboard only worked in your word processor because it demanded exclusive access and none of the other applications on your computer could use it once the word processor was opened. That’d be silly right?

I started killing processes on my system one at a time until the joystick finally started working again. Killing Google Chrome is what did it. Why on earth would a web browser be touching my Joystick hardware?!

After a bit of research and a run through Chrome’s source code (isn’t open source great?), I discovered a new system in HTML5 compliant browsers like Chrome called Gamepad. Gamepad allows new HTML5 pages to access your joystick hardware! Because of the Olympics, the daily Google Doodles have been little mini games which are stealing Joystick access! So Olympics + HTML5 kills Joysticks in X-Plane….amazing.

The solution is a simple change for them. They just need to pass a different flag so that they share the device with other applications. I’ve already filed a bug and spoken with the developer and the fix will likely be in Version 22 of Chrome but for now, make sure your browsers are closed if you appear to be having intermittent Joystick issues on Mac.

Sometimes reality is stranger than fiction…

***EDIT*** I do have to say, I got an immediate response from the engineer in charge of this Chrome feature and within an hour the bug was fixed and checked in for release in future versions. I can’t ask for better support than that.

Posted in Development, Hardware by | 13 Comments

Beta 6 and more View improvements…

Beta 6 is out and with it comes quite a list of improvements.

We listened to some feedback and decided to bring mouse-look back but in a new and totally rewritten way. Originally, it was removed because as a MODE, it was confusing. Many users would pick it thinking it was “the” 3D cockpit mode and then be horrified that they weren’t able to use the mouse for anything else. Mouse-Look is no longer a MODE…there is only ONE mode which is 3D cockpit mode. This is the mode where you right click and drag to move your head and then use the scroll wheel to zoom…but now if you double right click, the view mode is locked into “mouse-look” so you can let go of your mouse button and the camera will still track the mouse movement. To get out of the mode, just right click again or switch views and it’ll disable. This works for users with a mouse and for users with a trackpad.

Quick-Look views have been fixed so that they now smoothly transition from one preset to another preset within the cockpit – without recentering each time. I do have to make an apology that your existing presets will no longer work with Beta 6 until you go to your aircraft folder and rename your preferences to *_view_prefs.txt. They used to be called *_prefs.txt. They won’t be lost or deleted, X-Plane just won’t see them until you rename them.

One other neat feature to note…it’s a really simple feature but I think it adds a nice touch of realism. As Tom was working on the Baron he said to us that since so many users like to start their planes from cold-dark-cockpit mode, they should have a way of using a flashlight so they can see what they’re doing before they get the plane powered up. What a great idea! So that’s what we did! Most aviators use a red flashlight to preserve their eye sensitivity so in the View menu, you’ll now see a way to Toggle on and off the Red flashlight. You can tie it to a keyboard or joystick button as well. There’s no menu entry for it but if you’d prefer a white flashlight, there’s a command for that as well so you can pick what you like best. Like all of the other fancy dynamic lighting in the sim, the flashlight only works with HDR enabled.

I’ll leave you with a little video demo of it to see while your X-Plane is updating to Beta 6 in the background.

Posted in News, View System by | 34 Comments

The Views – Updates to a very important system

Once Ben is done fighting his war on HDR arthropods, Beta 5 will make its way out to the masses. In it, you’ll find some very cool updates to the view system that we think will make sim-life much easier, more intuitive and more useful.

The first change is the removal of the “mouse look” in 3D mode. This was the mode where the mouse controlled your camera orientation just by moving the cursor around without clicking. We had some feedback on the feature and agreed that it’s really not a very useful mode. The mouse is needed to click on various things in the 3D cockpit and to have your head bobbing around while you’re trying to do that was just annoying.

To look around in 3D mode, you can still of course right click and then move the mouse to adjust the camera angle. You can also use your scroll wheel to zoom in and out of things. This has been in the sim throughout the 10.x run and will remain the primary means of controlling head movement (unless you use your keyboard or Track IR of course). Since many people find the right-click/scroll gestures to be intuitive and useful, I’ve gone in and made things more consistent. Now, no matter what view you’re in, if head movement or zoom is possible, it’s done with right click and scroll. It used to require a LEFT click and scrolling was not an option. This should immediately help people who had trouble with the left clicks activating their mouse-flying box.

The final change is a pretty important one. We’ve added a system called “Quick-Look” (QL from this point on). Technically, you already have QL but I didn’t want to point it out to everyone until I had time to make some improvements to the system which I’ve done for Beta 5. QL allows you to get a view just the way you love it…and then save it to a hot key/cmnd that you can recall at any time later to go right back to the same spot.

For example, suppose you’re flying the default King Air and you find yourself frequently positioning your head, tilting down and zooming in on the throttle quadrant to see how you have the aircraft configured. This can take some time to setup and if you do it often, it can really get tedious. Let’s assign it to a QL then! Get the view the way you like it, and assign it to QL1. Now, no matter what you do to your views, when you press QL1, your head position, orientation and zoom goes right back to your memorized view of the throttle quadrant. It’s not just for 3D cockpit mode either. It works in all aircraft-relative views so 3D Cockpit, Ridealong, Chase, Circle, Forward with Hud etc. The reason for that limitation, is that these views are saved a little differently than other things in the sim. These are aircraft specific preferences. This is necessary so that your views for the Cessna 172 stay with the aircraft and don’t interfere with views for the King Air etc.

Currently, you get 10 QL views per aircraft and they’re saved/recalled anytime you switch aircraft. The QL keys are number-pad 0-9 by default. So for example, to recall QL3, just press the 3 on your number pad. To save a view to QL3, just get the view the way you like it, then press CONTROL + Num-pad 3. CONTROL is the default modifier key to do memorization. Like most of the commands in X-Plane, these are customizable so you can wire them up to any button combinations that you want. Also, you can use your joystick buttons as well to recall saved views.

A word of caution…some of you may have already discovered the QL system in earlier betas. That version is a fairly limited prototype (it only works in cockpit mode) so please do not report any view bugs prior to testing Beta 5. Lastly, your aircraft QL view preferences are going to get trashed with Beta 5 so please don’t spend hours tirelessly getting your views perfect for dozens of aircraft.

***EDIT*** Here’s a quick video I took of some sample views that I setup in the default King Air.

Posted in News, View System by | 75 Comments

Still having joystick trouble?

As you are hopefully already aware, the Joystick subsystem of X-Plane was completely rewritten for X-Plane 10.10. It uses a much lower-level method of communication to essentially talk directly to the devices so that we have complete access to their capabilities instead of being limited to what a “middleman” layer of software feels like telling us…which is how things used to work.

While most of the bugs have been fixed as of 10.10Beta 4, there still remain a small subset of devices that are still having problems. Let me list the known open issues:

  1. Even after calibration, some devices still show their axis max limited to about 75% of what it should be when viewed on the Axis tab of the Joystick Dialog. In other words, pull the yoke toward you and it goes to 0, push the yoke away from you and it goes to 75% instead of 100%. This is not a joystick bug at all but in fact a UI bug that’s been around all along but just never visible until now. This has been fixed in 10.10Beta 5 which is coming soon. You can also go to the “Null Zone” tab and see that your axis does in fact have it’s full range of travel.
  2. Some hardware does not appear at all on Linux. This is not a bug! This is a security feature of the Linux operating system. The problem is, Linux is a multi-user operating system and it has to worry about permissions to devices that are attached to the system. Take a keyboard for example…imagine if another user logged in could see everything you were typing because he had read permissions on your device! Linux locks down permissions on devices that are not part of an exception. The way to create an exception is to create a UDEV rule. If you don’t know how to write a UDEV rule, google it a bit..they are not very complicated for the average linux user. If you’ve chosen linux as your operating system, we hope you possess the skills to configure it. Here’s a simple sample rule:
    KERNEL=="event*", ATTRS{idProduct}=="0bd4", ATTRS{idVendor}=="06a3", MODE="0666"

    Here the VID is 0x06A3 and the PID is 0x0BD4. These are unique codes that identify that brand/model of joystick and the rule says “When you see this device, chmod 666 it.” One way of finding your VID/PID is by doing “lsusb -n”.

  3. Some devices have hat-switches that appear to “stick” in the ON position. This is fixed in 10.10Beta 5 as well.
  4. Last but not least, there are some devices that have particular AXIS or HAT SWITCHES that simply do not work. So far, I’ve seen a Logitech G25 clutch pedal and a Logitech G940 hat switch that doesn’t work. It works in the windows calibration screen as well as X-Plane 10.05R1 but not in the latest version.

Here’s where you guys come in. If you have one of those two Logitech devices, please let me know if yours is working just fine or if you have the problem as well.

I’m also interested in hearing about other devices that are having the #4 issue as well.

Lastly, if you are having any other kinds of Joystick problems that do NOT exist in 10.05R1 but that DO exist in 10.10 that haven’t already been mentioned, please let me know.

You can file a bug and please include a Log.txt file from 10.10Beta 4 as well as a description of what’s not working properly and on which device.

Posted in Hardware by | 7 Comments

Some thoughts on beta testing

Having such a small development team, it’s very difficult for us to test ALL conditions in which X-Plane is being used. Each of our offices are littered with joysticks, laptops, desktops, loose video cards, hard drives and various other hardware. We do our best to always be making steps in the right direction but it’s a losing battle to keep our testing internal. A prime example is the recent Joystick debacle. I rewrote the entire Joystick subsystem on 3 platforms and tested it on all 3 platforms on all joystick hardware I own, and Ben and Austin did the same. We worked out all known bugs and then shipped it…and immediately we found hardware that caused crashes 100% of the time. Once those were fixed, other devices were still broken…some devices didn’t even meet USB compliance and we had to work around that issue as well. I can’t possibly own every USB Joystick device on the market so how on earth do we get the product to be as stable as everyone wants it to be?

The answer is simple…we rely on ambitious and courageous users to take the plunge and help us test it. Being a Beta tester is a bit of a thankless job. Sure you get an early look at the new goodies but it can be very frustrating since often, you can’t enjoy them without crashes, artifacts and other annoying bugs. Most users are happy to provide their feedback via the bug form, and now with the new automatic crash reporting system, we’re finding and fixing crash bugs in record time. A prime example is the Joystick crash. Within minutes of releasing 10.10Beta 1, I was aware of the crash and had  all of the information that I needed to solve it. And within 24 hours, we had a new build that took care of it. But that’s only useful for crashes, it doesn’t help us learn about visual artifacts or other problems. That’s where we need YOU.

After reading through the forums, it’s become clear to me that many people are just not exactly sure what it means to Beta test software so I’ve come up with my own list.

  1. Keep two copies of X-Plane. If you care to ever fly X-Plane for enjoyment, ALWAYS keep two copies of the simulator on your hardware. One on a stable release that you use for enjoyment, the other on the latest beta for test purposes only. Your sanity will thank you later.
  2. Don’t use the beta for recreation time. If you’re only in the mood to fly and have fun that night, stay away from the beta copy unless you don’t mind your flight getting cut short. Too many users expect to fly for 6 straight hours and become enraged when the sim crashes on short final. That’s Murphy’s law!
  3. Always stay on the LATEST beta. Users often say “The latest beta broke XYZ, how do i go back to the previous beta?”. The answer is you don’t and you shouldn’t. That defeats the whole purpose of beta testing! During a beta process, the code is often changing very rapidly. If we’re on Beta 6 and you’re still submitting bugs on Beta 2, you’re wasting your own time and you’re not helping the product. It’s important you keep up with development.
  4. Blame us, not your system. If it worked in Beta 3 but it’s broken in Beta 4, do NOT tear your machine to pieces trying to figure out the cause of the problem. Report it and let US figure it out. Time after time, I see users change their drivers, install service packs, uninstall and reinstall X-Plane, update their OS etc trying to solve the bug…when it’s probably OUR bug…not your computer’s.
  5. Beware of the placebo effect! _EVERYTHING_ affects frame rate. Time of day, clouds, location, aircraft, view angle, view direction, addons, plugins etc etc. Sometimes we’ll release a simple patch that does nothing but fix one bug that was unrelated to the rendering pipeline. I’ll poke my nose in the forums to get some feedback and see 10 users who all of a sudden claim to see some massive fps increase in performance and 10 users who see a massive decrease in performance. I role my eyes at the claims because it’s not a controlled experiment. For example, if you’re the type of person who flies with real world weather enabled, flying one day with clear skies may get you 60fps while the next day you may see 40fps with overcast. Heck, even departing from a different runway than the previous day can result in different frame rates. Running with the command line fps_test IS a controlled experiment. THAT’s the only way to be sure you’re seeing a change in performance. Don’t trust your instincts, gather data in controlled experiments.
  6. Always read the release notes (//wiki.x-plane.com/beta) for each new version. They’ll tell you what bugs are supposed to be fixed as well as what new features have been added. If you see a bug that’s claimed to have been fixed yet it’s still happening to you, that’s when you write a new bug report. If we didn’t claim to fix it, it’s probably not fixed in that particular beta.
  7. We need a Log.txt! When submitting a bug, ALWAYS ATTACH the Log.txt from THAT sim run. Even if you don’t think the Log.txt is applicable, attach it anyway. Tell us in as much detail as you can what you were doing at the time.
  8. We already know about your crash. Because of the new automatic crash reporter, there’s no need to submit a manual bug report for crashes! Let the system do its thing. If you remembered some details after the fact that you want to tell us, then go ahead and file a report. Of course, if the auto-crash reporter didn’t load up for whatever reason, that’s a good time to file a manual report.
  9. Tell us who you are and what you know. We really appreciate users who enter their email and comments into the crash report form. It gives us a way to contact you to get more information. This was invaluable to me when attempting to fix the joystick issues earlier in 10.10. A handful of really helpful users made the research a breeze.
  10. Be objective, not emotional. No one hates bugs more than we do but writing a rant instead of a bug report may make you feel better, but it makes me grumpy. And when I get grumpy, I attend seminars…and when I attend seminars, I feel like a winner. And when I feel like a winner, I go to Vegas…and when i go to Vegas, I lose everything. And when I lose everything, I sell my hair to a wig shop….Don’t make me sell my hair to a wig shop.
  11. Stop staring at the fps counter! It seems that many users are obsessed with their fps counter. “It went up this beta. It went down this beta. It stayed the same this beta.” Yes, the framerate is ONE useful metric to determine the software’s performance but it’s not the ONLY one and often it’s not the right one. Turn it off and fly! Enjoy the simulator. Sometimes there’ll be a bug in one beta that increases fps as a side effect because the sim is no longer drawing what it’s supposed to. Suddenly, some users are thrilled to see a 20% boost in performance and perhaps they don’t notice that half of the usual streets aren’t being drawn any longer. Ben fixes the streets and in the next Beta, all of a sudden they lose their 20% performance gain and are outraged that we “broke things again.”
Posted in Uncategorized by | 41 Comments

10.04 Beta 4 Released

10.04 Beta 4 was released last night. The changelog can be found here as usual. Remember, you have to run the updater with the box checked that tells it you WANT to participate in the beta testing in order to get this version. Bug reports go here!

Posted in News by | Comments Off on 10.04 Beta 4 Released

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