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.
In a past life, before I worked for Laminar Research, I was a plugin developer. So I’ll admit up-front that I might be the most guilty individual when it comes to this particular problem: log spam.
What do I mean by log spam? By log spam I mean printing information to Log.txt that isn’t necessary.
Log.txt exists so that we (and third party developers) can look at a single machine-generated file and get a strong idea of what a user did with X-Plane for diagnostic purposes. Therefore log.txt needs to contain three kinds of information:
Basic configuration information. We print your graphics card, your OS, etc. (In 10.30 we’ll even get your CPU type right on OS X. 🙂 It’s more reliable to log this than to send a user into ten different control panels to gather information.
Very basic event logging, e.g. what did the user do? Where did he start his airplane, what scenery was loaded.
All abnormal conditions, including error alerts that came up.
In particular, what we do not need to do is log the detailed blow-by-blow progress of loading in excruciating detail.
If I may use my own sins as an example, older versions of XSquawkBox shipped with debug code on that dumped the contents of its entire ICAO dictionary – thousands of lines of text. This information isn’t configuration (it’s not unique to particular installs), it isn’t an event – it is part of the event of loading XSquawkBox, and its not an error condition. What a mess! (Fortunately Wade has fixed this and turned such logging off in the newest XSB betas.)
Programmers write this kind of logging code to help trace program execution, but it’s important to turn it off – if we don’t, the log files get so verbose that everyone spends a ton of time just fishing through ten tons of junk.
Some more guidelines:
Log the presence of files or sub-modules that are user-configurable, but do so briefly. It’s reasonable for SASL or Gizmo to list scripts that do not come with the base package, or for XSquawkBox or Pilots Edge to list CSLs found. (This information lets a developer see what a user has done to modify the plugin.)
Don’t log the presence of required files unless an error condition occurs. An empty log can simply mean “everything went okay.” (The sim will already confirm successful plugin loading on a per-plugin basis.)
Log rare events, e.g. a flight starting, a network connection being opened. Don’t log events that occur at high frequency, like receipt of a single network packet.
X-Plane is guilty of log-spam too; I’m slowly trying to cut down on this. For example, spurious autogen-tree warnings are now gone from the log in 10.25r1.
Support Debugging
Sometimes you need all of that logging. My suggestion is: if your add-on is complicated, make a specific interface to get verbose diagnostics that users can turn on as needed. For example, X-Plane has an option in “operations and warnings” to dump verbose play-by-play network data to Log.txt. When you enable this, you can get a ton of information about network operations, but the log will also be totally over-run. The option is meant only for developers who are integrating with X-Plane’s UDP networking, and thus it has to be turned on by hand.
The OBJ engine actually also has such a trick – if you put the single word DEBUG (all caps) at the end of your .obj file, the entire OBJ contents will be output in detail to Log.txt. Again, this is a ton of information, available when needed, but off by default.
You can support verbose logging in your add-on with a script variable, a dataref, a change to a preferences file. Pick an easy mechanism, so that you can have users turn on verbose logging only when they need it.
Not Everyone Has Grep
Finally, a quick aside to my fellow professional programmers. You might be rolling your eyes and going: “Ben you idiot, it’s easy to filter the log. Everyone should just prefix their log entry and use grep.”
If we were all programmers, I would agree 100%. But please understand that aircraft and scenery authors have to look through the log to get diagnostic information about art-asset problems, and this is an audience that is sometimes not comfortable with command-line tools, huge 25MB text files, massive amount of text, etc. So we are trying to keep the log.txt more human-readable than, for example, dmesg on Linux.
