X-Plane 11.31 is available to test – run our installer, update X-Plane, and check “get betas”. Full list of bug fixes here.
X-Plane 11.31 contains bug fixes that we could get done quickly, that almost made it into 11.30, and that were high priority, e.g. crashing on some Intel GPUs is fixed, and the external visuals don’t randomly lose sync.
We do still have some other fixes to get in at a later time. For example, there are a number of particle replay bugs where X-Plane isn’t saving the data needed to replay the particle effect; we will patch those in a separate patch where we can add more data to the .rep/.sit structures.
Some users have reported performance bugs, and we are gathering data and looking into them, but I’m not treating them as a five-alarm fire. We’re at a point where we are making rapid progress on the Vulkan port, and I don’t want that progress to grind to a halt as we investigate OpenGL performance problems; we already know that the long term solution to OpenGL performance problems is going to be Vulkan, not stabbing the OpenGL code repeatedly with a fork in the hope that it’s better behaved.
If we find something blatantly wrong with the OpenGL code in 11.30, we’ll fix it, but when it comes to ensuring performance, the very fact that the engine is OpenGL and not Vulkan limits us. At this point the IHVs are making their best performance analysis tools for Vulkan and Metal, not OpenGL, and Vulkan provides an API where the drivers performance is deterministic. (What we’ve seen so far is differing OpenGL performance for basically the same hardware drivers.)
X-Plane 11.30 was a really big code update to X-Plane – it had a major update on our route to re-writing the rendering engine, hence all of the rendering bugs we’re fixing. Over the next few updates I think we’ll have less code change as we stabilize, paired with art updates. We’ll take gateway airports and we have some landmarks ready to go.
Hi.
I’m having issues since 11.30 launch with Saitek X55 Throttle and SLD button (number 24 on game interface). I filled a bug some time ago, but I was wrong with the reason (I pointed to the “toggle reverse” command, but not the button).
I didn’t have any news for a while, and I was hopping some kind of fix with this release. Since I don’t have any news concerning it (and I’m sure the issue is concerning XP, not the joystick), Should I file a new bug?
You are not alone. I just updated to 11.31 and I can’t toggle reverse either on the MU-2 Really annoying as toggling reverse is really important for stopping.
Try this
Remove the file “Saitek Pro Flight X-55 Rhino Throttle – Windows.joy” from Resources/joystick configs/ and try configuring Again
I sent to LR what I think is a fixed config. But for now that is the best fix available.
glad to hear more art updates and visuals are coming
… thank you for making our passion a pleasure.
We appreciate all the devotion and hard work.
Very much appreciate the scale of the 11.30 update, Ben. I realize the results for users has been a mixed bag, and no doubt that’s also been frustrating at a time when LR wants to “Engage warp speed now!” on the way to Vulkan. Given the difference that VR has made for my flight sim experience and that of many other users, I want to see the VR wave gain force. This is so foundational to the future of X-Plane it’s not funny.
With apologies to Leonardo, “For once you have tasted VR you will walk the earth with your eyes turned to your PC, for there you have been and there you will long to return.”
Even when I’m working on a client’s project in VR, once I start testing, I find it a let down to have to exit the sim. 🙂
…unless you actually like to touch real stuff: knobs, switches, tablets, yokes, pedals, radio headsets, pieces of scribbled paper etc. Like pilots do.
I hope we get a balanced development; one that excites and satisfies the VR gamers and the RR (real reality) people in equal measure.
I like v11.30, the possibilities and options it offers, and the growing XP community that’s mixing old-world flightsimmers (many transitioning, like me, from the other platforms) with new generation gamers – we’re all learning from each other but there’s a wide range of user styles/needs and it would be great if LR could openly set out to meet them all.
agreed… I understand the fascination with VR, but RR (real reality as you call it) is where it is at for me and all my simmer associates. Hopefully LR maintains a balanced design approach.
Wouldn’t have it any other way. When my VR gloves arrive, the project to match meatspace to VR space in my simpit shall commence. Knowing where my hands are and seeing them connect with a VR switch, and feeling the switch under my fingers for real, will be the best merge I can imagine between the two worlds.
Clearly this demonstrates your point: there will be a wide range of user styles and needs in VR, outside the cockpit as well!
It will take a lot to meet all those needs, and it won’t happen overnight or in just X-Plane 11. It’s going to be growing for many years to come.
Thank you very much. Great work
I am frustrated with VR performance challenges but I completely support LR decision to put full focus on getting Vulkan out of the door sooner instead of fixing these OpenGL issues.
Hello Ben,
Can you put more clarity/definition to this “fix”? I’m not quite sure what it means.
“XPD-9820 Removed custom scenery earth.wed files from new installs.”
Thanks in advance,
CD
This means the landmark sceneries won’t have any more earth.wed.xml files in them. As they are of no use for anybody. Just some house cleaning.
Vulkan is still expected to be the next update, correct?
(To prevent any bashing, let’s make it clear I’m not asking for an ETA, just checking if the roadmap remains the same as was presented last time) 🙂
No. There will probably be smaller updates _before_ Vulkan. I don’t want anyone going “hey, there’s an update, it fixed bug X and has gateway airports, where’s Vulkan?!?”
Less VR, more Vulkan! 🙂
They are not mutually exclusive!
You are right, programmers are able to work 24 hours a day, and there is the nighttime also 🙂
Ha ha ha that’s a fantastic quote. 🙂
In the testing that LR has done so far with Vulcan, have you seen a substantial performance increase?
It’s too soon to tell – we need to get the Vulkan code to a certain point to have a real Apples to Apples comparison.
Was that a Metal pun Ben? 🙂
Doh! Not an intentional one. We could have an Apples-to-Spocks comparison I suppose….
People spelling Vulkan (the API) with a C is so prevalent it is really beginning to grate to the point it is turning me into a pedant!
Just remind for not being forgotten: Steam
Just flew the F-4 on the deck at max afterburner from DCA up to New England in…20 min. As the wheels touched down at KBOS, the mutexes were still traffic-lighting the threads building car traffic back in Brooklyn. OK, maybe an exaggeration, but not by much. Even the ortho load could barely keep up most of the time.
You have made it clear Vulkan will open many doors long term. I’m on the edge of the seat (again, only mild exaggeration) in anticipation of upcoming blog posts (here or even better, Hacks of Life) describing what you folks will be able to do now that a truly multi-threaded render path is just around the corner.
I still say for XP12 LR needs to take a LOOONG hard look at another engine like Unigine and that fact it can do things the xplane engine cant … and Unigine has been used for flight sims and can things on the scale of solar systems so the “its a game engine not a sim” excuse doesnt fly any more
but the fact is the latest ver of Unigine supports DX11,12 and Vulkan along with VR out of the box has better detail lighting shader and water then xplane AND runs faster
the fact xplanes water looks like its from 1998 still is pretty sad and the fact the water reflection shaders eat at lest 10 to 20 fps some thing is more wrong then just porting to Vulkan is going to fix
its time rip off the bandage and move to out of the box engine for XP12
Go and use a Sim that is based on that engine. Your comment is offensive and lacks of any understanding for game development. LR does a terrific job over many years full of passion and dedicated to our hobby. I am just wondering why they accept comments like yours into this blog.
Thank you for your compliments! Comments are entirely based on the discretion and whims of individual LR employees. The general guidelines are “As long as it isn’t too toxic or threatening, too off topic, or going into areas of discussion we’ve already said “We. Aren’t. Talking. About it. Anymore.” It gets approved. Rarely, we might respond via e-mail instead. The comment section on developer.x-plane.com is a something we can’t devote too much time into developing and policing (moderating human behavior and interactions on the internet is extremely difficult to get right!) Comments we don’t like get deleted without question. Zip. Gone. But, in general, we don’t actually have to do that very much which is awesome! Every couple days when someone logs on to the blog to update something or specifically to cull comments, comments get reviewed in the WP panel. So, for the people who wonder “Where is my comment?” It might be some time, and it will be subjected to arbitrary decision making by busy devs as time permits. Sorry!
Keep in mind everyone, we do value the interactions here! Seriously, it does more good than harm which is why we have it. And again, only a very small minority of comments are ever trashed. We have a fantastic community, so thanks!
I somewhat disagree. I like to cite tech from other engines that seems missing or should be at least considered for X-Plane.
That being said, porting from one engine, to another seems more of a fruitless task to me, we’d be here waiting a while.
Even moreso, I don’t think Laminar are that ignorant to what is wrong to their own sim. Some of the engineers have deep-rooted/professional backgrounds in their industry. What we have/currently getting in X-Plane is not too far-fetched from what we’ve seen in other sims in platforms.
I do believe that a general artistic direction is missing from X-Plane. Colours look unsaturated, objects/environment not producing convincing shadows, repetitive ground textures, the current “skybox” or atmosphere depiction. But these are things I believe will come in time, and the tech for alot of those complaints are progressively and quietly coming into X-Plane. (I cite features such as particles for scenery [new particle system], environmental sounds [fmod], new water shader and tesselation [revamped shader system and vulkan])
I think we just have to patiently sit-tight.
In fact, a while ago, I asked Ben if they had considered licensing an engine like Unigine or the Unreal engine, and the answer was a simple “yes, we’ve considered it.”
What we have to understand is that it’s easy to fork out the license fees when you’re developing a triple A game like Call of Duty, or GTA, or whatever. But for a relatively small team like LR, working on a relatively small user-base software like X-Plane, I guess the decision to purchase or not a license becomes more complicated.
Having said this, X-Plane’s user-base increased a lot… it could be that it might be making more sense now to think about investing on a game engine. It would be awesome for us, for sure, but it’s LR’s decision… it’s their livelihood on the line, for us this is just a hobby.
I’m surprised Ben would say that, but I don’t know the context and it doesn’t really matter. Engine discussions are a constant topic. I think people see the awesome games and graphics that come out of Unreal and Unity and Crytek and SuperEngine 5000 and think if you applied it here we would get those things as well. This is not true! Not only would it require a massive re-write of MASSIVE chunks of X-Plane, it wouldn’t give that great results. Unity might take an Okay First Person Shooter and beef it up quickly until it is a Really Awesome FPS, but if we swapped our specialized physics engine for airfoil and wind interactions for one built to simulate any-game-but-especially-grenades-explosions-race-cars-and-rag-doll-bodies, we’d loose the incredible realism in flight. You can get shadows and reflections and glowing swords right out of the box with Unity because most games don’t try to give you a realistic simulation of flying over the entire planet. Having pre-made hallways and maps allows game engines to take all sorts of cheats before hand. We have an entire globe, so we can’t pre-cache shadows and reflections. Then there is the stuff that doesn’t really matter to us.
Unity and the like has WYSIWYG editors for placing entities and making a world. We have…. airports defined in WED. A global database built on WED. We don’t need complex tools for placing switches and gates and AI units. It gets us nothing, in fact, if we switched all our content creation to Unity et al’s tools, we lose everything!
X-Plane has its own engine, which is called X-Plane. Its specially built for our special needs and special data. To “switch engines” is to switch products and nearly start over and we’ll never do that. And I’ll also say this: for any other sim that wants to build on Unity and compete – good luck. You don’t get to be the best by letting someone else tell you the limits, even when they’re letting you jump over decades of hurdles relatively quickly and telling you they’re a platform not a box.
Some people need to print out that response, Ted, and tape it to their fridge. 😉
Thanks for taking the time to write the in-depth response.
Now…about Outerra…. 😀 😀 😀
Outerra is purely OPENGL based.
Whereas Xplane is moving towards Vulkan (the right move forward)
The only area where Outerra could be inspiring to Xplane is for third-party developers to learn from the concepts adopted in the Outerra engine – namely the algorithmic-based approach in reproducing a more lively and convincing world.
X-plane is already doing that to some level , in terms of its open-street-maps intergration and the auto-gen.
Where xplane is lagging behind outerra is only in landscaping.
xplane is having its own meshes DB or Hi-res world mesh addon — and the DB or airports is linked with this dataset — therefore no need to touch that….
Most important, if we could see a developer (or even core LM ) to create a layer the replaces the random textures covering landscape and mountains with outerra-like algorithm based textures — this will magically fill in the vast void world of xplane and bring it to life… the trees could benefit as well.
Vulkan will help pave way for all that soon without a sweat.
The rendering engine of xplane will not be tampered, but will render the landscape natively and smartly.
No need to lecture about Outerra. 😉 That was a complete, tongue in cheek bit of dry humor since, just like whining for other render engines, the Outerra conversation is a non-starter. Outerra is great for the notion of a completely empty natural world, but it can’t compare to the complexity and genius that is the X-Plane plausible world.
i think you REALLY need to look at what say Unigine can do it HAS been used for other sims and in fact does a lot of what you want already out of the box and let LR focus on systems and not engine performance
https://developer.unigine.com/en/devlog/20181227-unigine-2.7.3#67381f70359bde91c53875a8fa510832
some thing to look at they are even working on full earth model out of the box in the next update and already has tools that people have been asking for for years like road and mesh editing
really all LR would need to plug there flight physics engine on top of Unigine and BAM X-Plane 12 with a modern engine letting LR work on things like the G1000 and maybe an LR 540/530 G5000 etc and improving flight physics
HELL Unigine supports DX10,11,12, OpenGL AND Vulkan out of box along with Win, Linux and osX so its not like you would lose any thing
Any news when will the new flight model (experimental today) have its final version released?
Will XPD-7919 (environment lighting pop) ever be addressed? Why does it occur only at precise longitude locations? Try it: take off from KMTN at 615pm on March 22 with clear sky and fly a hdg of 240. When you reach -76.651, the sky will darken. headed west its always xx.651. headed east its xx.349.
Does it have to do with xplane switching dsf tiles?
please fix it.
Any fix for white clouds who turn purple and blue at night when, the sun goes down ?
I leave a report bug, and i have no addons for the sky or something else intalled.
I think the sun lighting have a problem with the earth when she goes down.
If it’s possible to fix that, it will be good 🙂
Best regards
Noticing that 11.31 is out, I wonder why the updater isn’t displaying how much data there’s left to download: I only see seconds remaining and the speed estimate.
The other think I always wondered: The updater seems to download more files than it displays: When does the display refresh? Why not displaying every file it downloads? Ok, I probably could not read, but I’d see that it’s making fast progress 😉
Finally: There are some files that are quite large (e.g. …default apt dat/Earth nav data/apt.dat or …Resources/shaders/bin/spv/terrain.xsa).
Can’t the updater try to update only the parts that changed? For example using an algorithm as described in RFC 3284 or as in rsync (see https://unix.stackexchange.com/questions/366583/can-rsync-update-a-large-file-that-has-only-changed-partially-without-full-retra).
That might save update time for users, and also keep the required bandwidth low when a new release is pulled by the public.
Thank you for your hard work, and for the update what’s new and exciting in X-Plane!
Between my own sim, and sims at work, we’ve got many different machines running Windows 10, motherboards in the z170 through z390, as well as X299 chipset families, using Intel I7-6600K, 7700K, 8700K, 9900K, and 7920X processors, using nVidia GTX 1080’s, 1080 Ti’s, and RTX 2080 Ti GPUs. All of these systems saw rather large reductions in frame rates with the update to 11.30, dropping some of them to 12fps.
While I fully understand keeping focus on Vulkan deployment, I will send my gratitude for your continuing to look for any low hanging fps shaped fruit in the OGL environment.
Many thanks,
Brett
If you saw a _large_ reduction in frame rate, please file a bug….we have diagnostic tools to see what happened. We don’t nkow of anything that’d cause a 1080 or 2080 to slow down.
Yeah, I have to confirm Brett’s assertion. I just made a quick comparison between 11.25 and 11.30r1 on Linux with a GTX 1080. I made all the settings and scenery the same. Saw ~100 fps on 11.25 and ~80 fps on 11.31r1. So I imagine there are situations where the frame rate is even lower and it would be a genuine cause for concern.
This is in the category of “perf issues I’m not going to look at right now” I think. While 2.5 ms lost is a big deal, the sim’s perf above 60 fps is pretty random and semi-reliable right now, and the best thing we can do for that is to move to Vulkan, where we can analyze perf to a level of detail where this is something we can act on.
@Ben Supnik:
After update to 11.31 release I am experiencing a serious crash due to syntax error in GLSL pixel shader code.
This occurs only when HDR is active.
Bug report has just been filed to Bug report tracker with subject “Crash due to syntax error in GLSL pixel shader code”