OK you folks have not heard from me in forever, but trust me when I say it is because I am busier coding than you can imagine!
We are getting very close to X-Plane 10.30 Beta 1, and the feature-list is simply extraordinarily huge.
These will all be “making it work just perfectly” type features to really dial X-Plane in to the point that it is doing the job it needs to do, free of bugs or other quirkiness that make complex programs difficult to use. I will be announcing the beta when it is ready for public testing (we have been in private beta for some weeks now).
Next: Here is a cool new helo that was just introduced for X-Plane:
I usually do not announce each new craft for X-Plane since there are so many of them, but in this case I just had to make an exception since this bird looks just so darn good.
So, look for the public 10.30 Beta soon, and give the Dreamfoil 407 a try if you like!
austin
I’ve been meaning to post something about 10.30 too, but every day is exactly the same: I wake up, think I should post a status update and go “oh, I’ll do that later when I’m too tired to code.” Follow that with: code all day, survive dinner and bed-time with a two-year-old, and inevitably I end up being too tired to even post a status update.
I’ll get a few details up in the next 24 hours. Having put it in writing, now I can’t put it off anymore.
X-Plane has been lacking a decent navigation solution for general aviation aircraft for a long time. The built-in GNS430 instrument could only do direct-to navigation and not use X-Plane’s FMS plans, making long IFR flights inconvenient.
In X-Plane 10.30 we are introducing a new generation of the X-Plane 430 GPS navigator, modeled more closely after the Garmin 430W that is very popular in general aviation aircraft. The 430W is a popular aftermarket GPS replacement in many older general aviation aircraft, because it is approved for WAAS approaches and thus an easy upgrade to allow flying instrument approaches at lots of smaller airports without ILS.
The new X-Plane unit can create and fly multi-leg flightplans in addition to the direct-to function:
You can create directs or flight plans using a worldwide database of airports, fixes and navaids:
Loading or saving the route works using the X-Plane FMS format. Many online services for virtual flight planning are compatible with that:
You can then navigate along your flight plan using one of different map views that provide situational awareness:
While flying under VFR, stay alert to any Bravo, Charlie, Delta or special use airspace in the United states (open database, user-expandable):
You will be warned when you are about to violate an airspace:
using the nearest airport function you always know your nearest alternatives for landing (though we all know X-Avion does a much better job at that!)
With a little help from your friend, knowing when to start your descend becomes easy:
Before landing, always know who to call:
For IFR approaches, load precision and non-precision approaches from a world-wide, updatable database:
Review approach transitions and initial approach fixes:
and then load any approach and transition into your flight plan:
Under ATC (read: when flying online) the vector-to-final function will often be used instead of a transition:
The X-Plane 430 is there to help you stay alert to common errors in approach navigation:
The GPS is capable of flying non-precision GPS-approaches with a localizer-like guidance and varying CDI sensitivity:
If you don’t see the runway at the minimum descend altitude, continue to the missed approach point and the flight plan sequencing will go into suspend. At the missed approach point, if you still don’t see the runway, begin your missed approach:
and then get help choosing the right entry to the missed approach holding:
The new GNS430 is a drop-in replacement for the old one, so every X-Plane aircraft equipped with the GNS430 automagically becomes more IFR-capable with the 10.30 update. We also provide an additional instrument in style of the bigger GNS530, that designers can use in their aircraft starting with Plane-Maker 10.30. It also allows for dual installations that can either use separate flight plans or cross-fill.
The interaction of the GPS with the rest of the panel, especially the CDI and the autopilot, has been improved, offering a few more options for aircraft designers. Two additional posts explaining the new options in Plane-Maker will follow shortly.
The database from which approaches are loaded is provided by Aerosoft. A current database will be provided once with X-Plane 10.30, and further updates will be available on a subscription basis.
You might have noticed stupid COM frequencies in some screenshots. This is not a bug, but a feature: X-Plane 10.30 supports 8.33kHz channel spacing, that is now mandatory in the European upper airspace and will become more important over the next few years.
For the inevitable question “will it have X and does it simulate Y?” I do have one answer:
I chose the feature-set for the 10.30 release carefully to fulfill two requirements:
It must simulate the functions I use every day. After spending about 40 hours flying a C172P with this equipment, I have developed some pattern in day-to-day use. The simulated equipment must have the functions I use every day.
It must simulate what I need for my IFR checkride preparation. I’m currently studying for the instrument rating. All IFR GPS functions that are needed during the lessons must be simulated so I can use X-Plane to practice at home.
This does not cover all functions of the real unit, but it covers what the pilot absolutely needs every day.
I have been working on visibility and fog-related bugs in X-Plane 10.30; two fixes will improve high-altitude long-visibility viewing:
10.25 has a bug where the fog color changes abruptly at the cut between DSF and planet rendering, particularly when atmospheric scattering is on. This is fixed in 10.30
The 64-bit version of X-Plane 10.30 will load 12 DSFs instead of 6, for longer-range drawing of detailed DSF terrain.
These comparison shots show 35k above KSEA looking at Mount Rainier with max visibility. (Note that at 35k feet, it doesn’t make a huge difference what ground visibility you pick – the planet-wide upper atmosphere model is almost entirely in control.)
X-Plane 10.25 32/64-bit
X-Plane 10.30 32-bit
X-Plane 10.30 64-bit
These pictures are taken at “very high res” – the most my Mac Pro can survive with an old GPU; you might get a little bit better definition on “extreme” res.
More DSFs
A few notes on loading more DSFs:
My current plan is that the 64-bit version will always load the 4×3 DSF box – if we have to make this a setting for compatibility we will, but I think it’s preferable to not add more rendering settings.
The 32-bit build will stay with a lower DSF count for memory reasons; generally speaking, I don’t think we will have any additional visibility improvements in the 32-bit build since we are almost always going to hit a memory wall. If you have a 32-bit OS, consider upgrading to 64-bits! (In particular, if you are running Windows XP, please upgrade to Windows 7 or 8 64-bit – there are no more service packs for Windows XP, so you’re just asking to get malware!)
In 10.30 the DSF loader can load up to 4 DSfs at a time (for 4×3) or 2 at a time (for 3×2). So if you have a multi-core machine, the load time should be better even though there are more DSFs being loaded, thanks to multi-core. (The limiting factor here is that adjacent DSFs can’t be loaded at the same time because their edges need to be matched.)
I am still hoping to address other low-visibility fog issues, but that code is not complete yet.
The Planet Could Look Better
X-Plane renders nearby terrain using DSFs, but it renders the very far terrain and entire planet using a single “planet” model, which is a textured sphere displaced by a normal/height map. As of X-Plane 10.25 (and 10.30) we are not including as much detail in the 3-d planet mesh as the data on disk contains.
This pair of pictures is 45k above LOWI; the second texture has the mesh spacing on the planet artificially increased from 3 km to 2 km. (The data on disk is at 1 km spacing, but my machine can’t cope with that.)
10.25, 10.30
Extended Planet Detail – Maybe for 10.40
You can see we pick up a little bit of definition in the far mountains. In the long term, I think we could ship a 500 meter planet mesh, which would make the far view in X-Plane as good as the close view used to be in X-Plane 7.
I’m not sure when we’ll ship a higher density far-planet, but I think it will have to be post-10.30.
If 1 km or 500m seems like bad resolution, do consider how far away the planet mesh is. With a 4×3 DSF box, the planet starts 100 km from the viewer. At 90 degrees FOV (an extreme case, but it makes the math easier) the screen is 200 km across at the DSF cut-over. With a 2 km planet grid, that means we will show 100 planet vertices left-to-right. At 1080p the planet triangles are thus at 20 pixel increments – not bad for a low res mesh.
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!
