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:
- Immediately rewrite your code to work with the release candidate and release it immediately, preferably before the beta is over or
- File a bug, clearly indicating what changed from the last shipping version. Laminar fixes the release candidate and by the time the patch ships, your add-on “just works”.
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:
- Do file a bug. We cannot maintain compatibility if we do not know there is a problem.
- Do not change your add-on (and definitely do not release that change). Most likely that change is a mistake, and when we fix the bug, your original add-on would have worked but your modified add-on is now broken.
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 I Am Late?
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:
- Your users will be grumpy about the 1 or 2 week period during which the add-on was broken – that time could have been zero weeks if you participated in the beta and
- I will be grumpy that you reported the bug after beta instead of during the beta.
Free Passes
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:
- Light sizes for billboard lights.
- Fixing buggy fuel consumption at high altitude.
- Feathering props on low oil pressure.
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.
Posted in News
by
Ben Supnik |
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:
- A build of X-Plane is called a “release candidate” if we think at the time we create the build that it could be an official release – e.g. there are no known bugs.
- Release candidates get an “r” in the name, e.g. 1040r1 is our first release attempt for 10.40. The previous builds had a “b”, e.g. 10.40b6 is the sixth beta of X-Plane 10.40.
- If the release candidate doesn’t have show-stopping problems, we make it official – at that point every user gets that version when they update, even if they don’t have “get betas” checked.
- We do not re-cut the build or rename the build. Instead, the “r1” remains in the name of the product forever in the Log.txt file and if you pick “Get Info” or “Properties”. We need this so that tech support can identify someone using the official release versus an older release candidate.
- The version on the startup screen simply reads 10.40 – most users flying the sim don’t care about r1 or r2.
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.
Posted in News
by
Ben Supnik |
This may have happened to you: you import the latest approved airport scenery pack from the X-Plane Airport Gateway and modify it. When you go to export your improvements back to the gateway, WED says your work is invalid and has a problem — but not in the changes you made!
Huh? If this was the approved airport on the Gateway, how can it also be invalid in WED? How did that other author upload the airport before?
You Get a Free Pass
What do we do if we find that scenery and airports have bad data that is causing bugs? What if we can’t just fix the scenery pack for you? The policy we’ve been using is: “you get a free pass until your next scheduled maintenance; then you have to fix the bug.”
The X-Plane Scenery Gateway is a good example of this. Sometimes we find new categories of authoring mistakes – I write improvements to WED’s scenery validation function to catch these authoring errors. These are errors like:
- Typos in taxiway signs – the old syntax makes a sign with incorrect letters.
- Overlapping ATC routes – with the overlapping routes the AI aircraft do not taxi correctly.
In other words, these are situations where the WED scenery pack, if left alone, is causing clearly bad things to happen inside X-Plane. This isn’t a case of “old style or new style”, it’s a case of “broken or fixed.”
So what we do is we set WED to reject these scenery packs on future uploads, but we do not delete the airports from X-Plane itself. In other words, the airports with serious mistakes get a free pass until the next time an author does scheduled maintenance.
Then when an author is working in WED and is going to update the airport anyway, the author must fix the problems we have found.
No One Likes a Fire Drill
This strategy is a compromise between two extremes:
- If we force you to fix your airport right now (e.g. “fix the airport or we remove it from X-Plane”), that’s not fun, that’s a fire drill. And having been exposed to plenty of fire drills myself dealing with the new OS X 10.11 and Windows 10 releases, I’m sympathetic to authors not wanting to have to stop everything to deal with an issue ASAP.
- If we never require that these kinds of problems be fixed, they simply won’t be fixed. The overwhelming evidence that I have seen from working on authoring tools for X-Plane for over a decade is that some authors won’t fix problems unless the tools force them to do it.**
So requiring the change when the author does maintenance but not requiring the existing shipped scenery pack be modified strikes me as the best possible compromise: we still get quick responses to serious bugs, but we don’t force anyone to drop everything.
* I do realize that some authors are incredibly diligent about getting their scenery to be correct even if the tools don’t force them to do so! But the goal here is to have all scenery be correct; it only takes one broken scenery pack in the hundreds a user installs to crash X-Plane.
It’s been a while since I’ve written a blog entry because…I’ve been working in the dungeons, coding for Android, unlike Ben who spends his days at Starbucks sipping lattes and writing blog posts all day. 🙂
Seriously, if you have not yet heard, we’ve finally released X-Plane 10 for Android. It was a long, arduous process. Maybe I’ll write about the experience in a separate blog post if anyone’s interested. Anyway, back to the product…It has the same features and pricing model as X-Plane 10 for iPhone/iPad and will remain that way for the foreseeable future. I don’t expect Android to lag behind like it has in the past. If anything, it will probably be the first to get updates since there’s no painfully slow Apple approval process to sit through.
Where’s the iOS Update?
This initial release on Android is identical to the current release 10.1.0 on iOS except for the additional of liveries! This update will be available for iOS as soon as Apple approves it. It’s currently sitting in their queue.
What’s the Android Plan?
Currently I’m in firefighting mode! As of today, there are 7,654 supported devices so needless to say, there are some device-specific crash bugs…most on devices that I was not able to acquire myself during testing. I’ll admit however, there are fewer than I expected. We’re currently seeing 90.4% crash-free users. This is low compared to our iOS stability of 99.5% however the industry metric for games is supposedly 97%. I can’t remember where I read that, but that’s been my pseudo-goal so I plan on releasing frequent patches until we get there.
Aside from hardware-specific OpenGL issues, the biggest source of instability seems to be with Google’s In-App Billing service. I’ve found and fixed some issues in their sample code which will help, but many users cannot even link up with the service! I have not gotten enough data to fully understand that yet.
An update to 10.1.4 has been pushed this morning. It should go live in a couple of hours. That should fix stability issues for some people but I don’t expect it to move the needle significantly until the In-App Billing issues have been resolved. Until then, I’ll keep at it!
What’s next for Mobile?
Android is a top priority at the moment. Until we reach stability there, almost all of my efforts will be focused on doing so. Once Android has settled down a bit, the work that we do will be for both platforms.
I know the map is a source of annoyance for a lot of people. It appears, unsolicited, when trying to operate the throttle. I can look into that.
We do of course have more aircraft and missions coming. I can’t talk about the specifics of those yet but our artists are very busy at work making more stunning planes.
But where’s the “meat and potatoes” features? Unfortunately, a lot of the feedback that I get is not specific enough for us to use. I see things like “I like Infinite Flight/Aerofly better!” which is fine…that’s a matter of preference. But WHY do you like it better? What features are you missing most?
So here’s your chance to chime in. What’s important to you? What will make the app fit your needs better? Please feel free to comment below. Get your friends to comment too. The more feedback that I get, the more I can make sure our customer’s needs are being met.
