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 x-plane.org).
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.)
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 intersection
s. 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.
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….
The Cessna 172SP isn’t the fastest plane, but it would get you there a little quicker if it was a twin prop.
(This is what happens when I leave the AI planes on while randomly testing rendering bugs in the middle of nowhere. On the bright side, the two planes do shadow each other.)
Here’s a thought experiment for you: you have a new version of X-Plane with new global scenery, new rendering engine options, new weather, a whole fleet of new planes, and new ATC. That new ATC is rewritten to support realistic IFR flight, the AI planes participate, the system includes ground ops and it uses audio files to “talk”. But the AI planes don’t have real-world liveries, and they don’t follow real-world schedules for major airports. What do you do?
- Release this new version of X-Plane with the ATC as is, and continue to improve it in a patch.
- Release this new version of X-Plane, but ship the old ATC from version 9, because while the new ATC is better, it’s missing some features that some users have asked for.
- Delay the release of the entire sim because ATC is missing some features that some users have asked for.
Clearly options 2 and 3 aren’t options at all; you wouldn’t ship the old ATC (which is clearly inferior to the new code) just because there are more features you could ship, and you wouldn’t withhold the rest of the new version’s features for the same reason.
No feature is ever done unless a program is dead. Austin hired me about five years ago to work on the scenery system, and it is no more done now than it was five years ago. It is a lot better than it used to be; more efficient, better looking, more realistic, etc. But the bar for what is possible keeps moving. That’s part of what makes working on flight simulation software so interesting.
In yesterday’s post I tried to clarify why we are using real physics in the AI ATC planes; a lot of the discussion surrounding Austin’s original announcement made some assumptions about where CPU time is spent that aren’t correct. This post describes how features are incrementally added to a release – without understanding release planning, Austin’s description of 20 AI planes makes no sense.
Stretching the Playdough
Programs aren’t just born whole, complete, never to be modified again. If there is one consistent misunderstanding of software, it’s this notion that you “build” software the way you might build a bridge or a house. The truth is, software is made out of a building material that is nothing like bricks or steel, and thus the engineering practices have to be quite different.
If you build a house and decide you want a different exterior floor plan, you’re pretty much hosed. No one is going to change the outer shape of a house because the materials used to build the house are not particularly pliable to modification. The cost of moving a foundation is about the same as building a new foundation, so modifications are made as minimal as possible.*
By comparison, code is a lot more like playdough than bricks or concrete. You want the master bedroom a little bigger? Great, we’ll just streeeeeetch it out. Code is always modifiable after it is “finished” – if treated right, it never hardens and sets, and this is why successful programs are often on version 10. The problems a computer program tries to solve change, but code can change with them.
So my first take-away point is this: if we add a feature to a program later, it is not because the program was “incomplete” or “unfinished” before – perpetual improvement is the expected norm in a healthy computer program. In fact, perpetual improvement is desirable because it lets us match changing technology and because it lets us incorporate feedback we get from our user base.
(There’s an old saw in computer software that the reason to put out version 1 is to learn what you did wrong so you can make version 2. That’s a bit of an exaggeration, but the truth is that the only way to get really solid user feedback is to put something out there and then listen.)
Roadmapping
Given that we expect our software to change perpetually, how do we plan? The answer is that we need a road map for the next several steps that the software will take as it evolves. By knowing where we are going we can be reasonably well-informed on the features we code now.
A road map of features needs to be prioritized for two considerations:
- What do users want first? The things we code first, we can ship first, so high priority features should go first.
- What features have to be implemented first? You can’t build the roof of a house first, and we couldn’t have programmed orthophoto paging of DSFs until we programmed loading DSFs themselves. Sometimes the features “have” to go ina certain order for programming reasons.
ATC AI Airplanes
At this point we finally have enough common vocabulary to sanely discuss the AI airplanes for X-Plane’s ATC. So far I have tried to establish that:
- The AI airplanes are going to get better over time.
- We will almost certainly ship ATC AI before the AI airplanes are perfect.
- The order that we implement ATC features will be a mix of what we think is most important and what has to go in first for engineering reasons.
The first stage of the roadmap was to use X-Plane’s built-in AI planes as AI traffic. There were a lot of reasons to do this as the first step:
- The code’s already there, so it let us get some airplanes moving around quickly. Inventing a fully separate system from scratch would have taken time away from the rest of ATC.
- Virtually every optimization that has been suggested (and several that haven’t been) can be applied to the AI ATC airplanes, so there’s plenty of room to get faster. (If we thought we couldn’t optimize, we might not have put the flightmodel in for AI at all.)
- By sharing the flight model code with AI, the optimizations we do pay twice – to make ATC faster and to make the framerate faster for all users.
- Inventing a new way to make airplanes (only for ATC) would mean two sets of editing tools, which would invariably mean worse tools in all cases.
With the AI planes running, we then have a lot of ways we can improve things. We can optimize performance. We can optimize memory use. We can increase the airplane limit. We can virtualize the flights (so far away flights exist only in the ATC DB and don’t use a “real” AI plane). We can sever the 1:1 mapping of airplane model to flight. We can recycle airplanes when they get too far away to be adding anything to the user experience.
Which techniques will we do, and what will the airplane limit be? I don’t know. Optimization really needs to be driven by testing – that is, we need to improve the system by measuring it to see what the next best step is, not by speculating about what problems we might hit in the future. Over time, we will repeatedly optimize and the capabilities of the system will steadily grow.
If you want to know the final specs and capabilities for the ATC system, I fear you’ll have to wait until X-Plane 10 ships. When we are in development, any planning for future features is just that: a plan. As we hit real bugs and learn more about the features, the plan can, and often does change. Thus estimates of what X-Plane 10 will do won’t be truly reliable until we ship.
* I should be careful here; I used to have these conversations with Sergio, who is a professional architect among other things, and he would have to correct me on a million different aspects of construction technology.
This is a repost of a reply I wrote on avsim that sort of grew out of control. In part II I will try to explain what we’re doing with the ATC system and how far we will get in X-Plane 10.0. Anyway, post follows.
I will have to write a blog post to go into this in more detail later, but I think a lot of what has been written here is wrong. Y’all started under the assumptions that:
- The flight model is going to be too expensive to run on AI planes and
- A table based flight model would be faster.
Those are both questionable assumptions at best…pretty much everything you can conclude from that is, IMO, dubious.
(I should mention at this point that I am unaware of any “dumbing down” features in the FM right now. My understanding is that we will pre-process control inputs in a number of ways, and the frequency of the FM can be set to multiples of the framerate, but even at the lowest setting, we do a full physics integration and the plane is the sum of the physics that are applied to it. I mention this now because I am about to speculate on some optimizations that _could_ dumb down the physics model, and I want to make clear that shipping X-Plane 9 does not do this!!)
Here’s the short version:
The most expensive part of the flight model is ground interaction – that is, the flight model doing collision checking with the ground and various parts of the airplane. When an airplane is “clearly in the air” (e.g. an initial test shows it has high altitude) the FM isn’t very expensive; when it is near the ground, CPU time cranks up as we make sure to get the touch-down characteristics just right; same with taxiing.
So if we want to make the FM faster, there’s really only one place to attack: ground interactions – it’s the lions share of CPU time. There are a number of simple things we could do to improve ground interaction. For example, we could stop checking for body scrapes – since X-Plane has to handle physics correctly even if the user lands gear up and scrapes an engine, the sim normally tests the full geometry of the plane against the ground (which is not flat, even at an airport) – that adds up. If we are willing to trust that the AI planes don’t screw up a landing* we could cut down ground check to only real landing gear, which would improve performance.
Now what if we did some kind of ‘lo-fi’ AI, whether it’s table based or it simply says “move the plane forward by this much” (E.g. a sort of track-based system)? If we want the airplanes to ‘sit’ properly on the non-flat airport surfaces, we _still_ need to do the most expensive part of the FM – the wheel-ground collision checks. So the total savings of a ‘lo-fi’ AI flight model would be very small, because at best we might partly improve the performance of code that doesn’t have much impact on the sim.
(To understand why you can only boost performance by attacking the biggest pigs, see here.)
However, there would be a pretty huge cost to a lo-fi flight model: we would have to code a SECOND implementation of pretty much everything we already do in the real flight model! We would have to have new flight model files to support this new alternate flight model. The opportunity cost here is in developer time…the time spent building a separate flight model could have been spent performance-tuning the real flight model…even if we had a second flight model, performance tuning time would now be divided between the two flight models, and neither would reach its optimal performance.
Besides my explanation above of why a lo-fi flight model wouldn’t really be a win, two more comments:
In software development, it often pays to try the simplest thing first, see how it works, and go from there, rather than speculate how a system may perform and write a ton of code up front before you have real data. This is what we are doing…the simplest thing we can do is to run the real FM on the AI planes, and so far it looks like it’s going to work reasonably. IF we hit data that says “no we have to do something radical”, then we will…when the data says so, and no sooner. So far indications are that the real FM is going to be fine, and this makes sense from what we know about its performance characteristics. We also know that we have a lot of tricks we could pull to make the real FM faster for AI planes (e.g. removing engine scrape-checks, per above) before we have to go and write a whole new FM.
And finally, dude, the real FM looks good. With the real FM, the AI planes move the way big heavy airplanes should move. They track the ground perfectly. If the ground has a bump and the airplane’s suspension is loose, it sways like it should. The control surfaces deploy with their real time. When you’re at an airport performing ground ops, you can get really close to the AI planes, and at that point these things matter! I speculate: once you take follow an AI plane running the real FM on the ground, it’ll be hard to go back to a ‘synthetic’ FM.
* This may not be a safe assumption…what if a microburst hits an AI plane?
I am down in South Carolina with Austin and Chris, working on integration issues with the new ATC system for X-Plane 10. One issue Chris is working on now: how do you fit the wide open design options of Plane-Maker into the narrow FAA categories for aircraft. If someone builds a rocket powered lighter-than-air piano with a tilt-rotor and a lift fan, how many miles of separation does that aircraft need from the 747 in front of it? What SRS category is Sponge-Bob Square-Pants, or a Steinway piano, or Snoopy’s dog house? (And don’t even get me started on some of the weird creations Propsman has sent me!)
Our current solution is to analyze the structure of the plane and use the most conservative criteria available. If your aircraft weighs a lot, it’s a heavy, no matter how you built it. If it has jet engines, it’s a jet, etc. This way airplanes modeled after real life will get correct categorization, and custom designs will at least receive some kind of vaguely sane handling.
(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.)
