If you have a computer that can handle more detailed base meshes, AlpilotX’s free HD and (for those with serious hardware, UHD) meshes are a really great looking enhancement to X-Plane. Alpilotx just released a new HD version of South America with more up-to-date land class and OSM data.
Here are comparison screenshots.
Update: the comments form is fixed – sorry about that!
I’ve been working a bit on scenery tools this week. Here’s a road map of some of what’s coming up.
We are working on a release of the latest scenery gateway airports for X-Plane 10.45. Like all releases, we’ve found problems with airports that WED does not detect. So I will try to release a new version of WED with stricter validation soon.
Austin is working on new code to place static aircraft at unused ramp parking spots. I’l describe this in more detail in another post, but here are some key points:
Static aircraft in parking spots will ship next year, not this year, but is planned as a v10 update.
I made significant progress this week porting WED for OS X to 64-bit and modern Mac APIs. This effort basically meant rewriting the OS-level UI code in WED to be new AppKit based calls instead of the old Carbon API.
What this means is that developers will be able to build all of the scenery tools on a modern Mac running Yosemite or El Capitan with X-Code 7. Since Chris has already updated the projects to compiled WED in MSVC, a developer can build all of the common scenery tools from the most widely used open source IDEs.
It also brings us closer to a 64-bit WED on Mac, which is desperately needed since OS X provides the least amount of usable address space to 32-bit apps. I am not sure of the 64-bit status of the Windows WED build; it may need more work on the libraries.
This might be the most significant scenery tools development: we’ve been working with Ondrej (der-On on Git-Hub) on new features for the Blender 2.7 exporter. This will include:
Many of our artists still use 2.49, but there’s no question that 2.49’s days are numbered. It’s a question of when it stops working on OS X, not if. With the migration step, we can move our projects forward without artists having to redo work.
Like the previous 2.7 exporter, this one is open source and will be free, and should be able to export existing 2.7-type projects with no modifications – we are trying to maintain full backward compatibility.
* This situation is slightly silly – if the user picks the ramp start to fly, the user will be on top of a static aircraft.
X-Plane 10.42 is a small bug fix release, and it’s out now as a free update for all X-Plane 10 customers, Global Edition, Digital Download and Steam. We also updated the installer on Monday.
With 10.42 out, we’re looking to get onto 10.45 ASAP, which will include the latest set of airports from the X-Plane Scenery Gateway.
I’d like to see us release new airports from the gateway every eight weeks, as long as there are enough new updates (and so far that has definitely been the case). I’m posting that here, publicly so that when Julian and Robin are ready to release new airports and data and I’m going “um, well, maybe next week, I’m really busy and the kids threw up on me this morning” they can point to this post and go “eight weeks!”
X-Plane 10.42r1 is available for beta – the release notes are here. This is a very small bug fix patch that mostly aims to address problems we’ve found with digital download over the last few weeks. (We have already significantly upgraded the capacity of the digital download authorization servers, and a new installer release will finish this work next week.)
Even if you don’t use digital download, please do get the new build by running the installer, checking for updates, and checking “get betas”. Once some users have tested 10.42 and we release it, we can move on to 10.45 and more interesting things.
Since El Capitan came out, SASL has been crashing on quit when used in aircraft with customized sound. While I work on neither SASL nor El Capitan, both are (at least partly) open source, so I spent a few hours yesterday and located the bugs.
The good news is: this bug is fixed in SASL version 2.4. The bad news is: you’ll need to make sure the aircraft you are flying is using SASL 2.4 – and this applies to every aircraft that you have that uses SASL.
If you develop an aircraft using SASL, you can get the latest free version of SASL here. Note that this new version is apparently 64-bit only.
If you are using a freeware aircraft that is no longer supported, I think you could theoretically drop in the new SASL and see if it fixes things. If the aircraft is payware, the aircraft author might not be thrilled to have to support a “modified” aircraft and might prefer to do the upgrade in-house.
If you are a developer of SASL or you use OpenAL, you can read the gory technical details here.
Here’s a pop quiz: you download the release candidate for a new X-Plane patch – maybe it’s 10.41 – and you run your add-on. To your horror, you find that a dataref is missing – or maybe a command no longer works. Do you:
Pencils down! I have said this before, but I’ll say it again: the answer is choice number two – file a bug.
If you find a problem with your add-on during a beta where something used to work and now does not:
We try really, really, really hard to make sure that you don’t have to cut a new release of your add-on just because we are issuing a free update to X-Plane.
What if you are using the new shipping version of the sim? You just got 10.41, but you didn’t try any betas, and you find your add-on is broken.
File a bug. We will still fix the bug, and issue a patch. The only difference here is that:
Even if we find a bug that requires a modification to your aircraft to fix, we still try to put a compatibility mode into X-Plane so that you don’t have to release your aircraft immediately. As I blogged before, shipping add-ons can get a free pass. In these cases we sometimes recommend you update your add-on when you can, but there is no requirement that you must update to match our new update. Update when you can, on your own schedule.
We did hit three bugs in X-Plane 10.40 for which you do have to update your aircraft to get the benefit of the bug fix:
In all of these cases, we couldn’t apply the bug fix correctly to all aircraft – the changes would have positive effects on some aircraft and negative effects on others. So you get a free pass to leave the aircraft as is until you next save it in Plane-Maker; at that time you can make sure that the results of each bug fix are working for your aircraft. More details here.
X-Plane 10.41 release candidate 3 is live – check “get betas” to update to it using our installers, or enable betas on Steam to get it via Steam. Hopefully it will go final within a few days; r3 fixes the stupid version number typo and also fixes a bug in our crash detection analytics and the instructor station.
Please try X-Plane 10.41 release candidate two by running our installer, updating, and checking “get betas”. More notes here. Release candidate two gets in the datarefs that I (stupidly) forgot in RC1.
This build should go final this week!
I cut X-Plane 10.41 release candidate 1 last night – to get it, run the X-Plane Installer, pick update, and check “get betas”. Here’s a list of bug fixes.
10.41 is just critical bug fixes – fixes to crashes, and fixes to third party aircraft that didn’t make 10.40. No new features, no new airports. The goal here is to get these fixes out rapidly.
If your third party aircraft worked in 10.36 and does not work with 10.41 release candidate 1, please file a bug ASAP. We do not have any remaining open bugs with aircraft compatibility.
Steam users: we’ll cut a Steam version of 10.41 in the next few days if we don’t get any other reports – it’s the same plan as last time.
A number of users have asked me about why a build is sometimes named 10.40r1 or 10.40. Here’s how it works:
In order to remove the “r3” or “r1” from the long version of the build name, we would have to re-cut the build, which would mean a needless update and download for everyone, but more importantly, there would be a small but non-zero risk that we introduce a bug in the final version that was never tested in the release candidate.
You can see this strategy on OS X too – the OS version is 10.10.5 in the about box, but if you use the System Information App you get 10.10.5 (14F27) – that last cryptic number is the build identifier – it’s sort of like our r1 or r2.