For my final post on airport authoring, a few comments on the sharing process and moderation process. This is where we’ve gotten the most questions about procedure, etc.
A New Website
Traditionally, airports have gone to Robin Peel – he maintains a private SQL database where submissions are tracked.
We have a developer working now on a new portal website for the global airports – the website will support upload of new airports, tracking of airports by administrators, and downloading of pre-release airports before they are brought into X-Plane.
The site provides back-end tracking for us so that we can see what has been submitted and changed, etc.
To upload data on the site you’ll need a free account – this way we will have contact information for anyone sharing airports. (Very often we want to email the author and say “could you please fix the one PAPI that is facing in the wrong direction.”)
The Ratchet
The big question is: what about quality? How will we fix problems in the shared airports, and what will the quality bar be?
My current thinking is: quality should be like a ratchet: no user submission should ever make things worse than they were before. Over time, this will allow us to continually improve the airports.
This means a few things:
If you upload a newer version of an airport, and your work is worse than what was there before in some way, your upload will probably not be used as the new official airport version. For example, if you add buildings but accidentally delete a runway, the upload is worse and won’t be used.
This also means that you have to include every type of data present before-hand. If the previous airport has buildings, you need to include these buildings in your version even if you are only editing ATC data. You can’t upload just one kind of data.*
If you upload new data (E.g. new buildings) they don’t have to be perfect. We should not reject uploads because they aren’t as perfect as possible – over time we’ll ratchet up quality. Let’s walk before we run.
On the other hand, if your upload just looks totally broken, expect it to not be used. If there are no buildings at the airport and you put a hangar on the runway itself, we can’t use it.
One reason that we want you to include all data in every upload is that it’s important to check that the data is all synchronized. If users submit apt.dat and ATC data separately, the taxi routes could be misaligned from the pavement and the authors would not see this. By having everything in your package you can see that alignment is correct between all data sources before uploading.
Moderators and Collaboration
The system is being designed to support multiple moderators; one thing that seems clear so far is that the work of keeping an eye on this data has gone way up now that we have buildings too.
If there is a conflict between two legitimate layouts, both very good but different, we have the emails of the authors – we can email both and say “you guys work out a compromise for the location”.
One final thought: I have seen a lot of postings on forums, email to me, and blog comments, all expressing concern about what to do about bad data and how to stomp it out.
I think it’s important to take a step back and not get too carried away here. The goal of the global airports is to share data, with the moderators spotting bugs. No author that I have spoken to has ever said “I really want to post bad data to your database!” The moderators will be more like editors of a book than police catching criminals.
I bring this up because I have participated in other crowd-sourced projects, some that presume the authors are innocent until proven guilty (e.g. they assume authors know what they’re doing) and some that are guilty until proven innocent (e.g. no contribution goes up without a super-thorough review).
Invariably, the more relaxed projects end up with significantly more contributions, and in the long term end up with higher quality data, driven by a larger and more motivated authoring community. By comparison, the projects that put a huge emphasis on stopping contributors from erring as a primary goal end up deterring user contributions, and end up with worse data as a whole due to a lack of man-power.
One thing Robin has done right for quite a long time with X-Plane’s airport (which might not be obvious – sometimes when you do soemthing correctly its invisible) is to not alienate contributors who have had data quality issues. I want to make sure that we preserve a positive attitude toward contributors as we grow the global airport process.
Since X-Plane 8.50, airports have had a border polygon that defines the boundary of the airport surface area. The airport boundary polygon is probably the least understood aspect of airports, particularly because it takes effect when we cut DSFs, not when you load X-Plane.
The airport boundary does a few things:
If sloped runways are not enabled, it defines (roughly) the area that X-Plane will flatten to the airport elevation. If you have ever entered a silly field elevation in WED and then turned off sloped runways, you’ll see that the flattening process is not exact.
When we create base mesh DSFs, the area of the boundary polygon gets a grass surface texture.
When we create base mesh DSFs, the area of the boundary polygon has no autogen buildings. (These two points are actually one in the same – the zoning of ‘airport’ in the DSF creation tool adds grass and removes autogen at the same time.)
When we create base mesh DSFs, the elevation under the boundary polygon has large bumps and spikes removed.
No More Bezier Curves
If you’ve used WED 1.2, you may have noticed that it refuses to validate airports with bezier curve boundaries. This is because we are trying to stop the use of bezier curves for airport boundaries.
The problem with bezier curves is that they can very easily be self-intersecting, but WED has no good test for this. The result is (apparently) valid WED airport layouts that later crash the DSF generator. Every time we cut DSFs, we find a handful of boundary polygons that need to be hand-fixed due to bad bezier outlines. There were 3 in this last batch.
Furthermore, the DSF generator cannot actually use bezier curves – it has to convert them to polygons. So the author will not get a surface area like the one they expected – there is a conversion that must take place.
Faced with a bezier curve technology that produces crashes and isn’t actually used, I decided to switch to straight polygonal airport boundaries. So: when you work on new airports, please remove bezier curves from your boundary polygons.
One of the top 5 bug reports I see: two AI airplanes starting in the same ramp start position, or worse, an AI airplane starting on top of the user’s plane. The pictures are often quite spectacular, if not what we intended for the ATC system.
A crowded start.
The 7 engine Boing-Douglas DC-10-747 needs an escort helicopter.
A tri-tailed airliner?
The code that allocates AI start locations is much improved for X-Plane 10.30, so in the next major update, we should get less cluttered ramp starts.
But the code change isn’t enough; there’s something that you have to do now if you are working on an airports.
You need to provide more than one ramp start! In particular, if there aren’t enough ramp starts for a given airport, X-Plane cannot sanely allocate AI airplanes with space between them.
In the past, X-Plane’s UI didn’t have room to show a lot of ramp starts, so authors would include only a handful. This has been fixed for a while, so I encourage you to add lots of ramp starts to your airports. This will give the AI planes room to park and the user a choice of all of the real-world gates.
Types of Ramp Starts
X-Plane 10 introduced type and equipment codes to ramp starts. One thing Chris found while working on the ATC system was that users were putting ramp starts in silly locations. For example, some airports have ramp starts on the active runway! He had to write specific ATC code to untangle the disaster that happens when an airliner decides that “on the runway” is a good place to park.
X-Plane 10 lets you define your ramp start as a tie-down, a gate, the interior of a hanger, or ‘misc’. The misc category was designed for ramp starts that might be interesting to humans (e.g. “in the run-up area for runway 7”) that are not appropriate for AI/ATC use.
I am not a fan of ramp starts near the active runway; I figure if a user wants to minimize taxi time, X-Plane lets you start on the runway, and a start anywhere but the ramp is inappropriate for realistic flight. But whatever you make, consider marking real parking spots as gates, tie downs, etc. and the random starts as “misc”.
Static Aircraft
Static aircraft (3-d models of aircraft that don’t move) are a nice way to make an airport look busier with less impact on framerate than AI planes. But this presents a problem: if a static airplane is at gate C4 and a user wants to park there, what do we do?
I believe the solution to this is to automatically place static aircraft based on ramp starts. This is not something we have coded now, and I don’t know when we will get to it, but my design idea for static aircraft is to have the airport include a lot of start positions and no static aircraft; X-Plane can then place static aircraft at ramp starts based on a rendering setting, with the user picking more static aircraft if hardware permits.
The advantage of this scheme is that (because X-Plane places the static aircraft), X-Plane would know where they were parked and could make sure the static aircraft aren’t in the user’s spot and the AI aircraft aren’t using a spot taken by the static aircraft.
The todo item for authors to someday support sim-placed static aircraft is, fortunately, the same thing authors need to do now to prevent future AI collisions: just make sure that there are a lot of ramp starts, modeling how the real airport works.
Edit: Just to clarify, 10.30 is not scheduled to contain a big pile of ATC bug fixes. The slight improvement in AI ramp start placement that I put in was a one-off bug fix; more ATC bug fixes will come in a later patch.
Now that we have user-contributed airports with buildings in X-Plane 10.25, I have a few topics to cover regarding airport authoring. The first is taxi routes. (I will get to the contribution and sharing process in a few posts – please bear with me.)
The short of it is: if you do not provide taxi routing in an airport layout, X-Plane will generate a taxi route, and the route X-Plane generates is not particularly good. The algorithm is slow, so it hurts loading time, it produces a relatively ugly layout, often with errors, so the AI behavior is bad, and I suspect that sometimes the whole algorithm crashes.
While all of these things can be improved, there will always be a trade-off between load time and algorithm quality. For example, the layouts could be rendered using more memory, but the loading would be even slower.
And we don’t want to be generating AI layouts – we want this data to be in the apt.dat where it can be built by smart humans who can carefully author.
For example, consider an airport with a huge tarmac, where the taxi routes are simply painted onto a big slab of concrete. The AI algorithm doesn’t understand this line structure at all – it isn’t smart enough to ‘get’ the taxi instructions. So the AI network lets the plane drive straight across the slab of concrete, traffic flow be damned! The AI also has no idea what any taxiway is named, so ATC can’t provide good route names.
JFK auto-generated layout – note how irregular!
At T junctions, the aircraft ‘dip in’ to the T.
Large paved areas get near-random traversing route structures.
The pictures above show the actual generated taxi layout at KJFK – red indicates active segments where the aircraft hold short before crossing runways. Nerds will recognize that this layout is created by a straight skeleton erosion algorithm, a strategy for analyzing images that comes from OCR.
The moral of the story is: while the AI taxiing behavior can be quirky, a lot of the problems come from X-Plane trying to auto-generate layouts off of the apt.dat file without a real taxi route structure. If you create such routes, the sim loads faster, provides better directions, and provides more plausible taxi routes.
I’ve marked WorldEditor 1.2.1 as final. If you are a WorldEditor user, please upgrade from 1.2 to 1.2.1. Besides fixing a bunch of bugs (including annoying usability bugs), it changes the format of the zip files for submissions to the global airports to a format that is a lot easier for us to handle on our end.
The next version of WED will be 1.3 and will include more usability features; we’re not sure what else will go in that bucket or when we’ll cut it off and kick it out the door.
We’re on release candidate three of WorldEditor 1.2.1. RC3 fixed export of 970 airport files to include frequencies and fixed a bug where you could end up with a two-point hole in a polygon (which would then cause the airport to fail validation).
Hopefully this is the last RC and we can call WED 1.2.1 done shortly.
The addition of airport buildings to the default installation of X-Plane in 10.25 makes it much more important than it used to be to prioritize your scenery packs. It also makes it much more important that custom scenery exclude the scenery below it.
I have heard reports of users going into X-Plane and deleting the airports we ship to deal with conflicts. This is way more work than necessary, will be undone by the updater, and simply isn’t necessary. So this post will explain how you can sort out scenery conflicts without having to change content.
Some Light Reading
I try not to write up documentation in the blog – it’s not really useful to require users to search 900+ posts to find something I mentioned off-hand in a beta four years ago. So I wrote a knowledge base article. Please go read the entire article. I’ll go get another cup of coffee.
Let me summarize how things are supposed to work:
Custom overlay scenery packs should be higher priority than our airports. If you went out and got a custom scenery pack, you almost certainly want to see it, not our work. (Note that if you get X-Plane, run it once, then install custom scenery, this is what happens automatically.)
Custom overlay scenery packs should have exclusion zones to mask out the scenery below them, whether it is autogen, airports we ship, or rogue trees that have decided to invade a runway. (The need to exclude what is below you is not new – this has been in the sim since X-Plane 8.
Mesh scenery packs should be lower priority than our airports if you want to see our airports on top of custom mesh scenery. (This step is not automatic.) Mesh scenery excludes everything (think of the mesh as one giant excluzion rectangle) so you can’t have overlays below meshes.
Where Theory Meets Practice
My favorite Farside cartoon ever is a picture of two sets of engineers standing next to the ends of two highways that were clearly meant to connect – the highways are misaligned and do not connect. The caption: “Where theory meets practice.”
And like the cartoon, the reality of scenery packs doesn’t meet the theory in a few ways:
Some custom airport overlays don’t have exclusion zones. There was nothing under them in the past, so the authors didn’t bother to exclude.
Some users have their global scenery at the wrong priority level. The easiest way to have this happen is to delete scenery_packs.ini – the prioritization is lost and our airports end up on top.
If you install a base mesh into X-Plane, it goes to the top of the priority list, which is stupid; it needs to be below all of the overlays.
What is particularly concerning is that users way of fixing this (going in and editing the actual scenery packs) is probably making the situation more complicated, not less. Here’s what I think needs to happen:
Custom scenery authors need to start excluding their scenery. This isn’t a new rule; I consider it a bug to ship an airport without exclusion zones. If you have a custom scenery pack and it doesn’t have exclusion zones, ask the author to add them. It is not that hard to add a few exclusion zones in WED.
Users need to stop deleting their scenery_packs.ini. The .ini file is there to help you resolve conflicts, but it won’t work well if you constantly delete it. Once you set up your priorities properly X-Plane will not change them! Put your base meshes on the bottom, default airports in the middle, custom scenery in the top, and you are ready to go.
X-Plane needs to get the priority of base meshes correct when they are first installed – the fact that users have to go and ‘fix’ the scenery packs list is really annoying. We are looking at ways to fix this now, but unfortunately we don’t have any plan that we can execute in 10.25. This is high priority for a future update.
X-Plane needs to keep its own overlay scenery (the airports we ship, the demo areas) at a lower priority than any custom overlays that users add. This is the expected behavior and should be totally automatic.
Exclusion Zones and Custom Scenery
A number of authors have rightfully complained that the exclusion zone is a blunt object and doesn’t provide a way to carefully integrate autogen and custom scenery.
I agree, but I consider the problem to go significantly beyond exclusion zones; there is no way for a custom overlay to “edit” base vector data (e.g. to say “I want to move that road over there.”) The underlying data doesn’t have any kind of identifier to refer to it, and the underlying data can change if we recut and take newer OSM data.
I think the future solution to this lies not in more precise or powerful editing in overlays, but rather in the fact that we’re getting more network bandwidth, and the global data we have access to is getting better. Therefore the solution is to (1) push updates to the base scenery and (2) ensure that the base scenery is correct. With this process working, misalignments between custom scenery and the default scenery will be less important, and authors can simply fix small but ugly bugs in the base scenery (via OSM) and the result will be better scenery alignment in an update.
Exclusion Zones and Shared Global Airports
It is possible to include exclusion zones in an airport you share with the global airport database for inclusion in X-plane; some authors have already done this.
There are some cases where an exclusion zone is a must-have:
If the airport gets a new runway, there will be autogen in the location where the old runway used to be; a draped polygon + exclusion zone can “clear” the area for airport.
If the airport has trees on the runway (a bug in the default scenery) you can “fix” the bug with an exclusion zone.
The global shared default airports are one case where I don’t think we need complete exclusion in an overlay – they are meant to be the lowest priority overlay, and therefore don’t need to exclude other scenery.
I just built a release candidate of WorldEditor 1.2.1r2; if you work on airports, please try it and post a WED bug if something is really borked.
There are a few minor bug fixes, some usability tweaks, and two major ones:
The export format for sending zip files to Robin is modified to make things easier in the collection process. For this reason, we’d like everyone submitting airports to go to WED 1.2.1.
The library view now hides the resources marked private or deprecated in X-Plane 10.25 or earlier. So WED 1.2.1 and X-Plane 10.25 provide a much less cluttered library view. (WED 1.3 will have a nice improvement to filtering as well.)
For more details on what changed, all commits to WED 121 are visible here. (The commit notes are listed, and the yellow tags tell you the version where we then re-shipped the code.)
We are discussing internally how to handle a more permanent airport submission tracking system. My current thinking is that eventually we’ll build file transfer directly into WED – that is, you’ll say “share this airport” and WED will call up our servers directly and send the airport; no zip files and email. But that’s for the future.
X-Plane 10.25b2 should be “real soon” I think – I’m just waiting on one more change to cut the new beta.
I just posted a beta of WED 1.2.1; hopefully it will only take one beta to get this quick “bug fix” patch done.
Some usability fixes:
Locked and hidden items don’t cause clicks to select their parents.
The interior of an airport boundary is not selectable – it never should have been.
The marquee tool will never select the “world” entry on the hierarchy.
The click hot spots of handles don’t shrink at low zoom – they were doing that before, which made clicking hard.
(Basically Chris tried to use WED and got really annoyed*, so we dug in and fixed some of the smaller annoyances. The ones we left (like how locking works) need a major rework and can’t go into a bug fix.)
1.2.1 also filters out the private and deprecated library items (once you have X-Plane 10.25, beta coming “real soon now”). This should make the library display a lot cleaner. Also, hidden airports won’t export or fail validation, which is what you would expect.
The only other changes are a bug fix for exporting polygons on a DSF edge, and a bunch of changes to help Robin collect global airports.
If you are using WED 1.2r4 to make airports, please try 1.2.1b1 this weekend, and file bugs here.
* Which was difficult to differentiate from his normal state.
10.25 is coming along well; if nothing really bad happens, we should have a beta either for this weekend or next Tuesday. There are just a few remaining bugs left.
I’ve been looking through the collection of submitted lego brick airports, and I am impressed with what the community has done. In the collection I count 237 customized airports, with a total of 32,152 object and .agp placements. So I am thrilled that people are using WED and starting to bring life to their local airports.
(I’ll post some pictures and we’ll have an official list later; right now I’m still in the process of checking the airports to make sure they don’t crash the sim, etc.)
There’s a lot more to blog on the subject of airports and WED, but one thing has become immediately clear from seeing people’s work and the questions that have come up from LR employees: the library is a big cluttered mess and it makes it hard to find and use art assets properly.
The WED 1.3 code (available in GIT for nerds) already has better library filtering and sorting (another one of Ted’s contributions) but I’m trying to get a very basic quick filtering feature into WED 1.2.1 and X-Plane 10.25: categorization of the library.
In my current design I have three categories:
Public. This is the stuff you should be using to make scenery packs. The lego airport bricks are all public.
Private. This is stuff we meant to use as sub-parts of other art assets; they really should not have been exposed in the library. (The right thing to do is to use the parent art asset.) Often the private sub-parts contain fractions of a complete art asset and don’t make any sense on their own.
Deprecated. This is stuff that used to be public, but now isn’t a good idea to use. Often the deprecated art assets contain empty stub objects, in place only to keep old scenery packs from crashing. For example, there are actually library paths for X-Plane 7 ENV radio towers – these would be marked as deprecated.
The categories affect WorldEditor, not X-Plane! If your scenery pack uses a private art asset, it will work just as well under 10.25 as it did under 10.20. The goal is to filter the library in WorldEditor, so that authors can:
Find the good stuff faster.
Not use internals and old stuff by accident.
In its first revision, WED 1.2.1 won’t yell at you or flag you if an art asset is private; it just won’t show it in the library for additional use. We’ll work on a more refined set of interfaces in WED 1.3.
This is a major architectural change to the library, and I’m not thrilled to have to shotgun it into X-Plane 10.25. But the situation right now is pretty unmanageable, and I hate to see people adding private art assets into their scenery for any longer than necessary.
Authors: comments welcome! If this is going to break how you make scenery, please say so. If there are other ways you think this feature should work, please say so.
Everyone else: I’m going to be a hard-ass and delete off-topic comments. This post is for authors to discuss public, private and deprecated library paths only.
