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.
Like most major updates to X-Plane, we are working on a quick bug-fix patch, and it will be out soon. (This will be 10.41 and will only aim to fix critical bugs.) At this point it’s looking like I’ll have a 10.41 release candidate up Monday.*
There are unfortunately a few things that are causing a ton of bug reports that we can’t easily fix in X-Plane.
New Gateway airports will not go into 10.41; we’ll get more airports released as soon as possible once we get major bugs fixed.
There is one more bug I am looking into: quite a few users are seeing crash in audio code, only on – all together now – Windows 10. Since we ship a DLL of OpenAL I am hoping we can figure out what’s going on and fix it. I’ll post more when I get more info.
* Last night I finally reproduced a bug that I have suspected for a very long time: if you have a third party scenery library that modifies the cars and the right set of conditions happens, X-Plane will crash.
Nearly every bug report I’ve seen of this is of the form “I was just flying for a long time and X-Plane crashed” – no user had figured out that it was (1) traffic related or (2) due to third party libraries.
I should have a fix for this in 10.41 but in the meantime if you are in the “I was flying and crashed” camp, try turning off cars and see if things stabilize. If things get better, you can turn cars back on in 10.41.
Posted in News
by
Ben Supnik |
A ton of new stuff came out yesterday! Everything shipped! Here’s a summary…
X-Plane 10.40 Is Final
X-Plane 10.40 is now the official release of X-Plane, for all users. This includes Steam users! X-Plane 10.40 features hundreds of new 3-d airports, extended visibility with faster DSF loading, and just a ton of new features. Here’s a short summary of what’s new if you haven’t been in the beta. Here’s a really long summary.
Two gotchas:
- Windows 10 users – if you let X-Plane auto-update and it fails with “Permission Denied”, you can work around this by running the X-Plane Installer directly (with X-Plane not running) and update X-Plane directly. Once you have 10.40, the next auto-update should work.
- We have a handful of bug fixes that didn’t make 10.40 final – they’ll be in a 10.41 patch later this week or early next week.
Control Pad – Control X-Plane From Your iPad
Control Pad is a remote instructor’s station app for iPad and iPhone. You can set up and modify your flight without exiting the cockpit; it’s great for training.
Control Pad is free and works with X-Plane 10.40.
X-Plane 10 Mobile for Android
X-Plane 10 Mobile is now available for Android in the Google Play Store. This is the same modern X-Plane 10 Mobile that we shipped for iPhone/iPad last year. The app is free to fly, with in-app purchase of additional aircraft. Like X-Plane 10 Mobile for iOS, every plane features a custom working 3-d cockpit. More details here.
The Android release features new liveries available for free that are not yet available on iOS – those liveries are coming to iPhone shortly; the plan is to have the same features on iOS and Android, just like we have the same features in X-Plane 10 Global on Mac, Windows and Linux.
(The religious wars over smart phone operating systems are even more crazy than Mac vs Windows. It will be interesting to compare sales of the two mobile operating systems – this is the first time we’ve truly had the same product on both operating systems for an Apples to Apples comparison.)
Posted in News
by
Ben Supnik |
After a few false starts, X-Plane 10.40 release candidate 3 is now available to Steam users.
Steam users: to try the release candidate, you’ll need to go to the “properties” of X-Plane (in the steam client) and opt in to betas.
(If you can’t figure out how to do this, you should not opt in to betas!)
As with all pre-release software: if you would be annoyed by a crash or bug in X-Plane, do not try the beta or release candidate. The point of betas and release candidates is to find bugs, not to get X-Plane updates early.
Posted in News
by
Ben Supnik |
Another post in the category of “things that go wrong due to stuff in your operating system”: some users have had problems automatically updating X-Plane when using Windows 10. The error manifests itself as a “permission denied” error when the installer tries to update X-Plan.exe. No one within the company has ever seen this error but we have seen multiple reports from users.
One user was exceedingly patient and ran half a dozen tests for me and sent me back mini-dump files; via this process I think I have learned what is going wrong.
- When X-Plane goes to auto-update itself, it has to quit itself after launching the installer. If it does not, the X-Plane.exe file cannot be rewritten to a new version because it is in use.
- A DLL (PlayToDevice.dll) gets a chance to run shut-down code as part of the OS process-shut-down procedure. PlayToDevice attempts to de-register notifications of MIB changes and in the process hangs X-Plane.
- When the installer goes to update X-Plane.exe, X-Plane.exe is still running (since it is hung unloading PlayToDevice.dll) and the update fails.
The bad news is: I have no idea why this is happening, what is special about the users who have this problem, or what could be causing it. I couldn’t find any useful info on PlayToDevice.dll (if you know what this is, I’m all ears) – it’s definitely not something we asked the OS for.
The good news is: you can work around this problem quite easily:
- Quit X-Plane yourself.
- Run the installer directly from the desktop and
- Pick “update x-plane” and the update will work normally.
This isn’t as easy as auto-update, but it does still work.
A Possible Fix in RC3
I was able to jiggle the shut-down code to not hang one user’s system – this barely counts as a “bug fix” since it’s just me changing the order of shut-down calls and hoping something works out. But in case it helps all users, this fix is in 10.40 RC 3.
A note of warning: since the fix is in 10.40 RC3, all updates to 10.40 RC3 will have to be done by hand if you are affected. Once you have 10.40 RC3, the next update should work correctly. This delay is due to the bug being in the version of X-Plane being replaced.
Posted in News
by
Ben Supnik |
X-Plane 10.40 RC2 is out now. This RC has a few key bug fixes:
- RC1 had a bug in the file scanner that would cause some key frame tables in OBJs to be misread. This could cause add-ons to look wrong.
- There was a shader compile problem on Linux, definitely due to bad GLSL.
- I tracked down an out of bounds memory read in the autogen engine.
At this point I believe there is going to be an RC3 tonight because:
- I have a reported work-around for auto-update failures on Windows 10. That’s pretty high priority – if auto-update doesn’t work, we get tech support emails from now until doomsday.
- There’s a spurious error message in the log. This should really just be considered cosmetic, but for some reason y’all are really, really, really concerned about error messages in the logs* so if we don’t fix it, my in-box will fill up.
Steam users: there will not be an RC2 on Steam – if RC2 is indeed replaced by RC3 within 24 hours, then we’ll wait for RC3 to go to Steam. The reasoning here is the same as it was with RC1.
Posted in News
by
Ben Supnik |
I have two updates on Mac-specific bugs. Windows users, now is a good time to go get another cup of coffee. Update: it looks like neither of these bugs can be fixed or bypassed within X-Plane, so they could be with us for a while. So I am adding instructions on work-arounds for Mac users.
Red Red Lines
There is a bug on recent Nvidia cards (specific to OS X) where, at high rendering settings, you’ll see a red outline around the horizon. At this point I believe that this is a driver bug.
Here’s the interesting part: this bug is fixed in the Mac drivers that Nvidia provides. (Yes – NVidia provides a driver you can run on your Mac instead of the OS X shipping one.)
Now here’s the down-side, before you go install this thing. When I used this driver, I managed to repeatedly hang my entire machine while using X-Plane. This doesn’t happen using Apple’s driver. So at this point I’d say “use at your own risk.”
(In Nvidia’s defense, the driver is targeted at after-market PCIe cards for pro users; use in a RetinaBook is “beta” and that’s what I did.)
We don’t have a work-around for the red line bug in sim – if I did, I’d have applied it. So this bug will probably be in 1040, and it will be up to you to either try the NV driver, wait for an Apple fix, or use different rendering settings.
Options for Work-Around:
- Turn down shadow settings until the artifacts go away or
- Install the Nvidia drivers and enable them in the menu bar control panel. (In the driver picker, pick OS X and you’ll find Mac after-market drivers.)
Crash Changing Planes or Quitting
Updated 11/20/15: this bug has been fixed – see here for the details.
If you get a crash when changing aircraft or quitting X-Plane, and the plane you were flying uses SASL, please don’t file a bug with me or send me a crash log. The crash is SASL crashing inside OpenAL. The crash is specific to El Capitan, and we don’t know what causes it.
This one is an area of on-going investigation; you can basically live with the annoyance of “crashing” out of every SASL aircraft or not use El Capitan. You already know how I feel about being an early adopter to new operating systems.
Options for Work-Around:
The problem is that the crash is when you unload an aircraft running SASL, so the bug appears to be “loading any plane crashes” – it’s really the unloading of the aircraft before that is causing a problem. So the work-around is:
- Launch X-Plane.
- Pick Quick Flight and enable “Show this window on every startup of X-Plane”.
- Quit X-Plane – it may crash since you are unloading a SASL aircraft.
- When you re-start X-Plane, pick the default Cessna and you will no longer be “stuck”.
If you are stuck on El Capitan and you need to fly SASL aircraft and you are seeing crashes, my suggestion is to keep Quick Flight enabled at startup. If you have Yosemite and fly SASL-enhanced aircraft, I suggest not upgrading.
X-Plane 10.40 RC1 went live last night – see the release notes for bug fixes.
If your add-on works in 10.36 but does not work in 10.40, please tell us four weeks ago. (But if you haven’t tested your add-on, please do so ASAP!)
If you find something is broken in 10.40r1 that works in 10.36 please file a bug ASAP!
Note that we do have a number of valid bugs filed that will not be fixed in 10.40 – these are mostly bugs present in both 10.36 and 10.40. The goal with 10.40 is to get digital download final and not introduce new bugs.
If we don’t find a major “oh noes” over the weekend, we’ll look at getting rc1 onto Steam as a beta on Monday.
Posted in News
by
Ben Supnik |
Release notes are (finally) updated. I’ve been stuck in a pattern of not getting the beta done until late Friday night (with the servers ready to go live Saturday morning), and the release notes whenever I can get to them.
With this release, we’ve moved screenshots and AVIs to the Output folder so that they don’t clutter up your main X-Plane folder and make it hard to find things. They’re not in their own “screenshots” or “AVI” sub-folders because the expectation is that you will do something with them, e.g. rename them, file them, email them, or delete them.
(If we wanted a permanent archive, we could show a “save…” file box like the Save Replay” option, but having us prompt you at every screen shot and AVI save would be totally annoying – it’s more important to be able to snap a lot of pictures.)
Windows XP support is fixed (after I briefly broke it). To be clear:
- Windows XP is within the system requirements of X-Plane 10 and will be for the rest of the v10 run.
- That said, I strongly recommend you not use Windows XP. It’s end-of-lifed, it’s not getting security updates, you’re basically just asking for your computer to get p0wned.
- When you do update, please update to a 64-bit edition of Windows.
X-Plane 10.40 had (for a while) new code to more aggressively manage the rudder when you don’t have a rudder axis assigned. This code has been removed, and behavior should match X-Plane 10.36. If you see weird behavior with the rudder, please set up X-Plane 10.36 and 10.40 side-by-side, and file a bug only if the behavior is different between the two builds. There are a lot of ways to have screwy control behavior that aren’t bugs (e.g. having mis-calibrated hardware).
We may re-visit auto-rudder in the future. The fundamental problem is:
- There are aircraft (most of them in fact) that you just can’t fly without a rudder.
- Some users won’t have rudder-pedal-equivalent hardware.
- We don’t want to turn off the laws of physics in X-Plane.
The inevitable result is some kind of AI in our control input subsystem to create rudder inputs to make the plane flyable. The big question is how clever that AI system should try to be. (The problem being that without knowing pilot intention, you can’t know what to do. Sometimes the goal is coordinated flight, sometimes the goal is intentional cross-control to maintain the runway centerline.)
Scrolling should be fixed in the advanced joystick button configuration screen; however if you are still seeing a bug setting up joystick buttons, please file a detailed bug report. We have had several bug reports that tell us something is wrong, but they have been very thin on details and reproduction steps.
Posted in News
by
Ben Supnik |
You may need your rant-proof goggles for this post.
In the last few years, we’ve seen the price of major operating system upgrades drop, down from $100-to-$150 to…$0. And free is a magic number – once you make something free, people install it without doing a lot of critical thinking about whether something is a good idea or not.*
This creates a software compatibility disaster for OS vendors, app developers and users.
- The OS vendors (Microsoft, Apple, etc.) try really hard to keep the minor patches to the OS from breaking compatibility. They need users to install updates aggressively to fight malware. So a break due to a minor patch is a rare thing.
- The OS vendors can’t keep legacy APIs going forever – at some point they need to change fundamental technology.** So they save the big changes for major versions.
- Major versions are now free – so users install a major update aggressively, taking incompatible changes that the OS vendors had to put somewhere, breaking their apps.
We first saw this with Yosemite, which caused us a bit of a fire drill, and now we’re seeing it with Windows 10, where I have just seen a pile of weird-o random behaviors that are specific and unique to Windows 10. At least some of them seem to be a clear case of OS compatibility rules changing at a major version.
So first, here’s my advice:
Don’t be the first pilot on the block to update the OS on your X-Plane machine.
Let someone else go first. These days new OS releases just don’t offer some new feature that is so totally awesome and amazing that you can’t wait a few weeks to see if the compatibility situation is good or bad.
In the long term, what we need is a new normal. Currently application developers depend on compatibility-breaking API changes happening at well-defined, infrequent, major inflection points, e.g. the full OS upgrade. But full OS upgrades are gone; Microsoft is saying that they’re just going to patch Windows 10 forever, and Apple puts out a new OS version so frequently that they’re not all that different from patches.
We could simply declare ourselves “not compatible” with future OS versions until we’ve had time to survey the damage, but that’s not a real solution – most users are going to update first and read the fine print later.
It may be that we have to follow OS betas much more closely. There’s definitely some irony here – I am always berating third party developers to retest their add-ons against X-Plane betas. (“We’ll fix the bug, just check your add-on!”) Third party developers have a good reason not to want to do this – they need to do real work on their new aircraft, not spend their time testing our builds. We have a similar view about OS betas – it’s a time-sink for us to keep re-testing X-Plane on the latest unstable crazy-town beta. (OS betas can be a pretty big mess, so isolating regression bugs that affect your product from general breakage is sometimes difficult.) But we’re in the same situation with Apple and Microsoft that third parties are with X-Plane: if you don’t report a problem, it may not get fixed.***
* This has had the effect of making free-to-play a near-requirement in the mobile market. If your mobile app category is even slightly competitive, then you are one of ten apps doing the same thing. A user will download and try every free app in the category before buying even one $0.99 app. So if your competitor is free-to-play and isn’t totally unusable and awful, you had best be free-to-play too!
** For example, Microsoft has been trying to evolve the rules about high-DPI devices and app resolution. This is a necessary step because monitors have become much larger and much higher DPI; keeping the old system forever would mean not actually supporting this technology.
*** Apple and Microsoft test third party products themselves to try to catch problems directly, and we now do the same thing with third party add-ons. But the amount of test coverage we can find is definitely not adequate to guarantee that your add-on is perfect coming out of beta. All we can hope to do is add another layer of defense.
