X-Plane 11.50 beta 16 is now out. Probably the most important bug fix is the set of fixes for broken plugin drawing–this affected SkyMaxx Pro and a number of add-ons in pop-out windows. Full notes here.
At this point we think we are good in terms of plugin compatibility APIs – if your add-on still acts funny in beta 16, please let us know ASAP.
Sidney and I spent a bunch of time over the last week looking at performance. Here’s what we have found so far:
X-Plane 11.50 beta 14 made cloud performance significantly worse on the GPU. I accidentally turned off optimized off-screen clouds. This is fixed as of beta 15.
X-Plane 11.50 beta 15 made CPU performance worse on AMD cards on Windows during panel drawing – the same bugs that caused the incorrect plugin drawing hit performance as well. This is fixed as of beta 16. (XPD-10943)
X-Plane 11.50 beta 15 leaks VRAM when scenery or the aircraft gets loaded. That doesn’t necessarily hurt performance but it’s definitely not good. This is fixed in beta 16 (XPD-10941). If you had blurry textures, definitely re-test now.
NVidia cards are losing about 1.5 ms of GPU time as a result of the bug fix for wrong reflections in Vulkan. We found the cause of the performance loss but we have not fixed it yet. This was introduced in beta 12 when we fixed the reflections. (XPD-10953)
Temporary slow frame rate or stutters when turning your head with Vulkan. If your frame rate is smooth and good when flying and then temporarily slows down only when your view changes as lot (e.g circling, turning your head, etc.), that’s this bug. The cause is slower draw time when we draw 3-d scenery out of system memory while we wait for the DMA to VRAM to finish. (XPD-10898)
From what we can tell, a huge percentage of the blog comment complaints about performance are all XPD-10898.
At this point, with beta 16, we do not want any additional performance bug reports. Given that we have two performance issues fully diagnosed but not fixed, there’s no point in collecting more data – the two existing problems would mask other ones. We are also drowning in performance bug reports at this point; we don’t have bandwidth to triage additional ones right now.
Amazingly, I think the answer (and I realize I am cursing the next beta by typing this) is we’re getting really close. You’d be forgiven for thinking that’s lunacy given beta 15; here’s a little bit of info about the state of the betas.
Cloud performance should be back to baseline norms for 11.50 – when I fixed a multi-monitor bug in beta 14, I accidentally turned off a major cloud performance optimization,
Fatal errors while resizing the window should be fixed. These squawks were coming from code that now checks much more heavily for error conditions, and revealed a problem when the OS delivers window resizes to us too slowly.
Note the introduction of new bugs in the process of fixing old ones – this is always a risk when a bug fix is intrusive or complicated; in order to get a shippable product, we have to keep ratcheting down the amount of chaos we introduce per beta, making smaller and more surgical changes.
Beta 15 also tried to fix one last plugin compatibility bug that we discovered very late in the game – under Vulkan, there’s no depth/stencil buffer available to third party plugins, resulting in incorrect drawing for previously working plugins.
I think you know where this is going…this new change introduced new bugs, even as it fixed the problem with the original add-on.
We have been working with third party developers over the last twenty four hours on fixes for the regressions here; our hope is to have a new beta on Monday or Tuesday that fixes these issues and has gotten a good third party once-over.
We’re Going to Have to Close the Door
We are reaching the end of X-Plane 11.50 – at this point the number of remaining bugs to be fixed in this beta is small enough that they aren’t that hard to keep track of. To get to a release candidate though, we’ll need to stop introducing major changes.
I am hoping that we already know about all of the third party incompatibilities, because at this point we have to close the door to complex changes to improve backward compatibility. For beta 16 we are fixing what used to work and is now broken (e.g. yes, SkyMaxx will work again), but if anyone is sitting on an add-on problem they haven’t mentioned, we’re out of time to deal with it.
Plugin Developers: Thread Safety!
Plugin developers: in looking at your compatibility with X-Plane 11.50, please re-read this post and check your usage of threads. We’ve had really helpful responses from third parties who we have notified about threading issues we’ve seen by auto-crash reporting, and I think this will help everyone–third parties, users, and us.
I believe that X-Plane 11.50 is significantly more sensitive to threading violations than 11.40, because the Vulkan driver doesn’t spend CPU cycles protecting itself from abuse. If a plugin calls into us from a thread when it’s not allowed to, this can cascade into crazy X-Plane behavior, which cascades into crazy Vulkan behavior that the driver won’t stop. So careful adherence to the threading rules by plugins is critical to Vulkan stability.
X-Plane 11.50b14 is available via the Laminar Research installer & Steam “Unstable Betas” channel. We’ll make beta 14 the standard Steam public beta version once we have a sense that it’s not completely unusable.
Highlights of this update include fixes for stutters and freezes we heard a lot about over the last week. We believe users on the latest Nvidia driver (451.48) should see improvements as well.
We have seen some early reports of problems with VR and performance, and some of them are already identified and will be addressed in beta 15. We are going to keep with beta 14 for now to collect more bug reports – it also provides smoother flight for NVidia users.
Catching Problems Early
The plugin system has an iron-clad rule–you can’t talk to the plugin system from your plugin from a second thread. This rule is important because if a plugin violates it, the resulting crash may happen later, somewhere else in the code, or might just be impossible to decipher.
Beta 14 addresses this by crashing immediately when plugins run certain APIs illegally from the wrong thread. The goal here is to clearly identify these problems as an incorrect plugin, so the plugin author can fix the problem, and we can tell how stable the rest of the sim is.
Here’s the gotcha: when a plugin crashes the sim by doing something illegal on a thread, X-Plane doesn’t diagnose it as a plugin bug – you’ll just get a standard auto-report form. This isn’t perfect, but we think a clear auto-reported crash is better than a confusing auto-reported crash.
We quietly released beta 14 yesterday afternoon, and so far, the top four auto reported crashes are all plugin crashes in threads.
Plugin authors: we will try to find you and tell you if we see your plugin crashing in threaded code by calling X-Plane.
X-Plane 11.50b13 is now available. Steam users, remember you can access this version immediately by opting into the “Unstable Pre-Release beta” version. We’ll make beta 13 the standard Steam public beta version once we have a sense that it’s not completely unusable.
Beta 12 was released on Friday, however we quickly learned it had a major issue: Windows OpenGL users couldn’t launch. Our build process had a hiccup that caused a shader mismatch, so we rolled beta 12 back in favor of beta 11 for the weekend.
Beta 13 fixes this shader issue, and includes all of the beta 12 fixes such as:
As always, remember that this is a beta, so make back ups!
We’re Going Back To Saying ‘Root Objects’
#544 – it appears the “Exportable Collection/Object” naming scheme was confusing. We’re going back to 2.79 phrasing “Root Collection/Object” in the UI, error messages, bug reports, feature requests, e-mails, everything. If I make a mistake please correct me quickly!
Our bright and shiny new fun feature is here! Automatic Lights (also called WYSIWYG lights) replaces Named and Param lights. It fills out parameters and aims directional lights for you in the most efficient way possible! No more doing math by hand, no more reading the lights.txt file, no more being scared to experiment! The UI guides you and prevents mistakes! Automatic lights are the new XPlane2Blender default light. Download this example to see many different uses of this feature!
We’ve tried to make this as intuitive as possible, but just in case you’re not sure what fills in what parameter, see this table:
Blender Property Used
Light’s color picker
R, G, B
XPlane2Blender’s Index property
XPlane2Blender’s Light Size property
Spot Light’s Rotation (in any mode)
DX, DY, DZ
“Omni” if light is a POINT else Spot Shape > Size
XPlane2Blender’s Flash Frequency property
XPlane2Blender’s Phase Offset property
Any other parameter found in lights.txt can’t be changed in Blender.
Some very very old lights are not compatible.
This is currently an opt-in feature only. An updater for old named and param lights would be difficult and limited and likely won’t happen.
A dataref search window style feature feature is planned, but currently to get a list of lights and their parameters you’ll need to click “Create lights.txt Summary” and look at the internal text block “lights.txt Summary
The lights.txt included is the same content as X-Plane’s lights.txt, with slightly different formatting. Your .obj will be completely correct in X-Plane, but X-Plane’s old and currently shipping lights.txt is not compatible with XPlane2Blender. This will hopefully be corrected soon.
Please send me pictures and stories of what you’re trying now that the light system is more easy! I can’t wait to see more sparkling lights across the skies and airports of X-Plane!
X-Plane 11.50b11 is now available. Steam users, remember you can access this version by opting into the “Unstable Pre-Release beta” version. We’ll make beta 11 the standard Steam public beta version once we have a newer beta.
Release note highlights include:
New UI option: anisotropic filtering
New Plane Maker option: always use Experimental Flight Model
Enabling the Experimental Flight Model in Plane Maker
The experimental flight model has proven to be quite stable since it was released in X-Plane 11.40, so authors can now set up their aircraft to use it by default.
The new check box is found in the Author screen in Plane Maker. When it is checked, the aircraft will always get the 11.40 experimental flight model, no matter what the user pref for flight model is in the X-Plane UI. You should use this option if you like how your aircraft performs with it enabled.
When the new check box is off (which it will be by default), the user pref decides what happens, just like 11.40. Aircraft creators should pick this if they target the older flight model. Note there’s no way to force the experimental flight model off.
An ongoing question in the comments section has been: “when will this beta be released for Steam?” It’s a good question! In the old days, the answer was “it’ll be a few days” because building a beta for Steam was a separate process from building a beta for the Laminar Research installer.
We solved that problem a few months ago; when we create a beta, we create the beta for both installers at the same time in one coordinated symphony of automatic scripts and command line witchcraft. But there is still some delay in making the Steam beta be available to users – we usually wait a few hours to make sure the build isn’t crashing for a big portion of our user base.
Now you don’t have to wait! If you are a Steam customer you can get the very latest beta even if it’s broken and unusable.
What Is an Unstable Beta
An unstable beta is a beta build of X-Plane that has some kind of relatively serious problem, or that might have a problem we don’t know about because it hasn’t been rolled out to the whole community.
Why would you ever want that? Sometimes the unstable beta has a bug fix you really need. Maybe the crashes affect common hardware but not your hardware. Maybe you just like really new things.
How To Get Unstable Betas for Steam
Our application now has two choices for betas – if you go to the betas tab in the X-Plane app properties in Steam, you now have both the choice of:
“Public Beta” – this is the beta you’ve been using for months – it’s a beta, so it may be buggy, but we don’t release it until we have at least a little bit of evidence that it mostly works.
“Unstable pre-Release Beta” – this is the very latest beta even if it’s broken.
You can choose which one you want, or even switch between them.
For example, right now if you pick public beta you’ll get beta 9, which, for better or worse, has been the current beta for several weeks. If you pick “unstable pre-release beta”, you get beta 10, even though it crashes in HDR with some third party aircraft (a new crash to beta 10) and people tell us that sometimes it hangs on load.
Should I Use an Unstable Beta?
Probably not? There are two cases I can imagine where the unstable beta would be more useful than the normal beta:
The current stable beta doesn’t work for you, so you might as well try something new.
You are waiting on a specific bug fix and the unstable beta has it.
What About Customers Not Using Steam?
We don’t have this multi-beta capability for our home-grown installer, but someday I hope to add it – I think it’s a really useful capability to be able to define multiple tiers of beta quality.
We had a long discussion a few weeks ago about ways to deal with broken betas and a lot of people though that rolling out betas incrementally would be a good idea. Having multiple beta tiers can help this.
X-Plane 11.50b10 is now available if you update via the Laminar Research installer. (Steam users: it’s on the servers and we’ll hit go in a few hours if we don’t hear reports of massive crashing and pain again.) You can view the latest release notes here.
This update has two major improvements: we fixed our top auto reported crashes, and optimized VRAM usage based on the reports many of you sent in. If you update to beta 10 and still see blurry textures, please create a new diagnostic report, and file a new bug report with it.
Normally I try to not mention specific add-ons when talking about problems; it’s not fair to the add-on maker, it’s really hard to know what the real problem is without knowing everything about the bug, the problems I blog about usually affect a wide array of add-ons, and I don’t want to throw add-on makers under the bus. It’s not fair to them, particularly in this case.
In this case, however, approximately everybody knows that the Zibo was missing its wings in 11.50 beta 9 – it’s a very widely used add-on, and it’s a perfect illustration of the problems with third party content validation, which is what this post is about.
So…gather round children, and I will tell you the tale of how the Zibo lost its wings.
With Vulkan and Metal, X-Plane is now firmly in the driver’s seat for VRAM management. This lets us eliminate stutters that were previously present with OpenGL and almost impossible to avoid. It has, however, one big and noticeable downside: when you run out of VRAM, you get blurry textures.
Of course the goal wasn’t to replace stuttering with blurry textures, and we believe that given the normal work load of X-Plane, you should not be seeing this. The fact that so many users are seeing blurry textures, especially on big cards with lots of VRAM, points to the VRAM code being buggy in all the ways beta code can be buggy.
How much VRAM do I need?
Just to get the obvious out of the way, our system requirements have not changed for 11.50. Our minimum VRAM requirement for X-Plane 11 is still 1Gb. We expect these cards to be able to run 1080p with lowered texture resolution, providing an equal experience to X-Plane 11.41. With 2Gb we expect users to be able to run HDR with medium texture resolution on 1080p systems. 4Gb and higher should be able to run HDR at with high resolution textures with 2k monitor resolutions. With 6Gb and higher, 4k monitor resolution should be possible.