Last week I spent a little bit of time looking at a bug: some ILS approach paths have tall buildings in the way. For an example, fly the ILS 22L into KBOS, and look to your right on short final. I hope the people living in those apartment buildings like watching airplanes!
A Library Bug
It looks like the bug is caused by a bad mapping of art assets in the library. The global scenery DSFs contain virtual paths for art assets, which are then mapped to real autogen art assets by the library. The virtual paths indicate the legal height ranges that the autogen can extend to, e.g. the library path
lib/g10/autogen/urban_high_solid_f_30x40_v0.agb
Indicates that this art asset fills a square block at least 30m deep with roads on all four sides, and the buildings should be between 32 and 40m tall for the tallest ones included. (The actual encoding of the library is partly handled by scripts we use to build the global scenery, and the encoding is byzantine enough that neither Alex nor I understand the entire thing.)
Well, if the virtual library path calls for a low building but the physical art asset contains tall buildings, you get skyscrapers in places you did not want them. And that is exactly the bug causing the ILS incursions.
I have an edit to the library paths for our next release (probably 10.30) that should fix this problem. The good news about this being a bug in the library (and not the DSFs) is that a single library fix will fix the problem everywhere.
For the Brave
(This is a hack to the sim…don’t try this if you aren’t willing to break your copy of X-Plane. If you try this and your sim dies, please don’t contact me or tech support!)
If you want to patch this bug yourself now in 10.25, simply locate the file
and replace it with this file: library.txt. Warning: because this is a mod to the sim itself, when you go to update, you will get a warning as to whether you want to overwrite the file. When the next beta or release comes out, do overwrite this file!
What About the Raw Data
I also wrote some code to attempt to ‘protect’ the ILS approach path in our DSF generator. Here’s a picture:
What you see here is a color-coded trace of height limits for autogen. Red are the strongest height restrictions, yellow less so. The height restrictions take into account not only the glide slope, but also the terrain; in the case of KSAN, the airport is at the bottom of a hill next to a mesa, so the ‘red’ (low flying planes) zone is quite large – even when a plane is on a 2 mile final, the plane is low to the ground because the ground is higher up.
The logic of the code is to let all ‘known’ tall buildings exist, but limit any generated tall buildings to follow the height restriction.
Here’s the thing: having coded it, I have not caught any cases where the autogen buildings were violating the height restrictions!
Buildings that we generate (without obstacle data) always have a maximum height that is a fraction of the FAA-spec’d tallest building. The idea is that if the FAA says there is a single 80m (roughly 20 story) building, then the nearby buildings are probably somewhat tall, but they’re not also 80m – if they were, the FAA data would include them. So we might generate some 40m buildings near the 80m building to create a plausible ‘neighborhood’.
From what I can tell, the fact that the generated buildings are so much lower than the FAA datapoints keeps them out of the approach path, and the actual cause of tall buildings has been the library path misalignment. (For example, in the KBOS 22L case, the block has an 8m height restriction and yet the buildings are either 50m or 70m tall, I can’t remember which.)
I think I am going to keep the ILS-protecting DSF generation code around – it’s useful to have approach paths noted, and it’s something we’ve been intending to do for quite a while. But the library fix is what will make a real difference.
AMD’s latest Catalyst Beta (Catalyst 14.2 V1.3) fixes the translucency artifacts in HDR mode. This driver also supports the newest cards and has correct brightness levels in HDR mode, so if you’re an AMD user on Windows, this is the driver to use. This change hasn’t made it to the Linux AMD proprietary driver, but it probably will soon.
I have received reports of faint red lines on the latest NVidia Windows WHQL drivers (334.89) under cloudy conditions, but neither Chris nor I have been able to reproduce them. If you can reproduce this, please file an X-Plane bug. (I have not reported this to NVidia because I can’t reproduce it.)
Some users have reported crashes with Intel HD 4000 GPUs on Windows; getting the latest drivers from Intel seems to fix the issue. I don’t have good info on what versions work/don’t work but it appears that plenty of machines have shipped with old drivers for their motherboard graphics. I believe X-Plane does run correctly with the Intel HD4000 series GPUs on Windows as long as the right driver is installed.
OS X 10.9.2 is out, and I think it may have new drivers (the NVidia .kext files changed versions), but I don’t see any change in framerate for either NV or AMD cards.
Update: NVidia has been able to reproduce the red lines bug – we’re still working out the details of what’s going on, but it’s a known issue now. Thanks to everyone who reported it.
If you find a driver bug on Windows or Linux, please repot this to us (via our bug reporter) and to NVidia, Intel or AMD. I try to bring known bugs directly to the driver teams, but having the bug in their public bug reports is good too – it makes it clear that real users are seeing real problems with a shipping product.
Here is a quick update on some of what we are working on. This post won’t contain everything, as some development efforts are still under the radar, and it’s not a comprehensive list of 10.30 features.
(I am not ready to post a 10.30 feature list yet; please do not comment with “will XXX be in 10.30”.)
The Airport Gateway. That’s what we are calling the website we are developing for sharing lego brick airports. The X-Plane Airport Gateway is under construction and has already reached an internal milestone; when finished it will be the portal through which you can share lego-brick airports with the community for inclusion in X-Plane.
We have decided to provide direct upload to the gateway from WED in the initial roll-out of the gateway; it’s a simpler work-flow and it is what we always planned to do eventually. So there will be a WED release (probably 1.2.2) to match the gateway.
I believe the gateway may go live before 10.30 goes final. (I believe this mostly because I think 10.30 will need a loooooong beta) so at this point we’re looking at how to transfer all shared airports into the gateway, rather than looking at how to release airports without the gateway the way we did in 10.25. We do want to upload all of the data we already have into 10.25.
Autogen. Alex is working on a set of autogen that will greatly improve the coverage, variety, and correctness of US autogen. I do not know when he will complete this task; we will release the work whenever it is ready, possibly in a point release of X-Plane just for autogen. Basically if 10.30 is in beta when he is done, the work will be rolled into 10.30 betas; if it isn’t, we’ll do a 10.35 or something for the autogen. The autogen is basically an art-asset update, so it isn’t strongly tied to X-Plane code.
Bug Fixes. A big part of 10.30 is bug fixes and quality improvements, and a lot of the bugs that we are working on are hard to fix. (If they were cheap to fix, we would have fixed them in 10.22 or 10.25.) Our view of X-Plane 10 is that there are a lot of new features that need tuning to meet their full potential, so we are trying to focus on high quality for what X-Plane 10 does, not on expanding X-Plane 10 into (even more) new territory.
As get some of those bugs fixed, I may post a few “call to test” posts – we are looking to do significantly more private beta testing in 10.30 to get specific features tested before the flying circus of public beta starts. (Please do not request private beta access unless we’re calling for testers. Our goal is to have new features and bugs fixed by people who are specialists in that part of the sim.)
Third Party Interfaces. We’ve built up a number of requests for datarefs, third party interfaces, etc. that we haven’t been able to implement in ‘small’ releases like 10.22 or 10.25. I’m hoping we’ll get through most or all of these in 10.30. I’ll write up more details when we get closer to a public beta.
DSFs. We still need to figure out how we will release DSF recuts, but they should be ready when 10.30 is; pretty much all of the work for the recut is already done.
I’ll post more on the 10.30 beta process in a few weeks when we get closer to it. As of now, the basic coding work for 10.30 is not yet done, so while we have some code to test, 10.30 is not “in the can”.
I think I have randomly mentioned this to various developers, so I might as well randomly mention it to all developers. A new particle system for X-Plane is in our road-map – that is, a particle system where authors can control the properties and graphics in detail (similar to what you’d get in one of the AAA game engines).
If you have feature requests or ideas for things you need for a particle system, please write something short and coherent and email it to me; I can file it with my design notes for later integration.
When X-Plane checks X-Plane.com for updates, it calls the server with an identifier for itself that contains a little bit of information about the host machine it is running on: operating system type and version, whether it is the 64-bit or 32-bit version, and whether it is running as a demo.* (X-Plane does not send any personally identifying information about you, but the server can see your IP address because all servers can see the IP addresses of all incoming network traffic.)
I sometimes get asked by third party developers: what percentage of users are using 64-bit, or what percentage of users are on Mac or Linux. So I wrote a script to analyze the incoming data and break it down by platform, etc. Here are the results. (I have done this kind of analysis before, but this is the first time I wrote a good script to remove possibly confounding results.)
Platform Breakdown
The data set consists of 24,917 unique IP addresses that ran a non-demo, global X-Plane 10.25r1 in the last week of 2013. This excludes users who have the regional version, a demo, don’t have their DVD in the drive, are running an old version, or who don’t have net connectivity. So that’s a big enough sample to get good data, even though it’s only a fraction of the total X-Plane 10 copies sold. Here’s the platform break-down:
IBM: 65.7%
APL: 32.2%
LIN: 2.0%
This matches the number we’ve seen ever since FSX development was halted: growing market share for Windows. (We used to be 60-40 Windows/Mac back in the day). Since X-Plane 10 is selling better than X-Plane 9, I believe that what we are seeing is growth, and the growth is disproportionately among Windows users. The Linux share appears to have shrunk, but it’s hard to tell since past data wasn’t as carefully analyzed. (The highest percent I have ever seen for Linux was 5%, but from this data I estimate the error bars on old data might be +/- a few percent, so who knows.)
64-Bit Adoption
Here’s the rate of 64-bit adoption for each OS.
All OSes: 82.0%
APL: 85.1%
IBM: 80.7%
LIN: 72.7%
It doesn’t surprise me that OS X has the highest 64-bit adoption – every Mac is running a 64-bit operating system and OS X has the least available address space. What does surprise me is that Linux has the lowest 64-bit adoption rate, since Linux users have had the strongest desire for 64-bit. (This desire is, I think, driven by the difficulty of setting up cross-64/32-bit operation on modern distributions.)
Operating System Breakdown
We don’t have a break-down of Linux distros or Kernels – the Linux version of the sim doesn’t report that, but we do have operating system versions for Windows and Mac. On Windows the _32 and _64 bit suffixes tell whether the user is running the 32 or 64 bit “edition” of the OS.
The numbers include the 64-bit adoption rate for that particular OS; naturally the 64-bit adoption rate on the 32-bit editions of Windows is 0% because those OSes can’t run 64-bit X-Plane. Fortunately 64-bit editions of Windows are becoming the norm – of the users running Windows 8, over 98% have the 64-bit edition. On OS X, every version of the OS is 64-bit capable.
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.
Update: this driver bug has since been fixed – see here.
If your X-Plane screen looks like this with HDR on, you may be running the new Catalyst 13-12 drivers. If you can, back up to the Catalyst 13-9 drivers to get back HDR mode.
(If you have a really new AMD card, you might not be able to run 13-9 – in that case please turn off HDR until AMD has a fix.)
This is a continuation of this problem – what’s new is that the 13-12 drivers are WHQL drivers and not just beta drivers.
Thanks to the users who reported this to me. I try to keep an eye on all driver combinations, but the help is appreciated!
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.
What you see here is a color-coded trace of height limits for autogen. Red are the strongest height restrictions, yellow less so. The height restrictions take into account not only the glide slope, but also the terrain; in the case of KSAN, the airport is at the bottom of a hill next to a mesa, so the ‘red’ (low flying planes) zone is quite large – even when a plane is on a 2 mile final, the plane is low to the ground because the ground is higher up.
