The initial beta for X-Plane 11.41 is now available for LR customers, and we expect Steam to be available within 24 hours or so.
This is a small patch that focuses on fixing a security vulnerability. Small bug fixes are also included, and you can see the full release notes here.
Could we get a better explanation of what “security issue” was fixed?
Full disclosure is coming! We need to get the patch out to our users first, particularly in non-beta form.
Hi Ben!
I’m going to take the opportunity of this bug-fixing release to ask you a related question, I think, about the technical debt of X-Plane.
I watched a video a few weeks ago about the technical debt of Kerbal Space Program 1.x, apparently being unhealthy big and impacting the stability and gameplay of that game…
So, just by curiosity, I’m wondering about the one of X-Plane. I guess it’s not very big and probably not an issue. How do you manage it? As that tech debt increased with the growing complexity of X-Plane (I guess yes)? Is it even possible to not have one due to the nature of coding and the inevitability of bugs?
Sorry if that comes out of the blue, maybe those are pretty uninformed questions and probably naïve/ignorant as well… But I would be interested to have some insight on that. Maybe you already touched on that with older posts but I’m too lazy too search 🙂
X-Plane is about 750,000 lines of code (roughly) for the sim not counting tools and surrounding infrastructure, so while we are definitely not a “big” program by the standards of the industry, we’re not small either.
Our approach to technical debt is to try to fully modernize a sub-system when we are focusing on it for feature reasons. So for example, the graphics engine is coming out of a major overhaul for Vulkan/Metal and it’s going to have basically 0 debt when we’re done – legacy issues got fixed as part of the restructure.
By comparison, the panel system is -not- being touched, so its debt level is the same as it was a year ago – no higher, no lower.
I push for this approach because it means the cost (in test time, debugging, and impact to users) of fixing old code is shared with new features we would do anyway.
Imagine if we decided to just fix technical debt in the panel code with no new features. We’d have an inevitable pile of panel bugs and incompatibilities for no good business reason. There’d be nothing _better_ about the new release from a panel perspective, it would just be screwed up.
Similarly, imagine if we decided to add new features to the panel without cleaning up some of the old code. Those features would take longer to develop and be buggier because they’d be built on top of rickety old abstractions that are in need of an update.
So I like to see cleanup and refactoring tied to the feature work in the same area – it makes the features cheaper to code while keeping testing down.
(With that in mind, 11.41 is not about paying off technical debt – it’s an “erata” release that just tries to kill off the few bugs that inevitably escaped 11.40.)
This is the best question-answer tuple i have seen in a while.
very insightful indeed.
i liked the way how Ben is addressing and managing the product development at the given resource and size.
Modernizing the code base inside out while upgrading the feature-set is a smart strike, which means that the XP engine is building more muscle overtime.
Keep amazing us.
Thanks Ben for taking the time to answer, it was very informative indeed 🙂
Damn was hanging out for some news on 11.5!
I hope Vulcan is the next release!
I prefer Vulkan. Why? Dunno, the logic escapes me.
I had been wondering why the announced “small and quick” 11.41 took so long to arrive.
eta on a Vulkan beta or even alpha be helpful for people getting ready to make upgrades over the holidays
You have to get ready for a click ?
Strange enough.
well you know depending on how its threaded a AMD CPU may be with 1% of intel but you know just throw money way if you dont have to
be nice to know this wile sales a going on
I’m afraid all those shouting for a Vulcan release will shout even louder if they get new bugs. Maybe being patient gives you a better Vulcan when it’s ready. Actually shouting at developers doesn’t speed up the development process IMHO. Don’t get me wrong: I have an ATI GFX card with poor performance in X-Plane 11, but I have > 100 FPS for some older version. So the new hardware is much faster, but the new software also is much slower. Well nothing new: We know that from Microsoft: Windows is always slow.
HA its Apple that is slow again with in 2 years apple will lock down OS X in prep to move to ARM and plug ins will NEED TO be signed with now work around enjoy your stock sim since no one that makes add one is going pay apple 500 bucks a year just to sign there free add on
whats that Apple is still using OGL 3.2? thats what 8 years old now
whats that Metal 2 is delayed again? and still isnt as fast as OpenGL even? huh
“Metal isn’t as fast as OpenGL”. What are you talking about? Also, Metal 2 has been out for 2 years now.
Its Vulkan, not Vulcan.
Thanks for XPD-10384! All the glider pilots are grateful out there!
The constant exceptions under Windows 10 are annoying. No matter what plane.
Exception thrown at 0x00007FFF3C0DA839 (KernelBase.dll) in X-Plane.exe: 0xE24C4A02.
Mostly i got these errors in the past related to overclooking cpu , ram and gpu. I solved the problem due to 100% stable clocks. I could overclock the GPU in other games about 30% stable without increase the core clock…in X-Plane i get random crashes with that overclock. Only up to 5% GPU overclock work for me. I am at 5.2 on an I7-8700k stable. That work very well but I could not get the full overclock power from the GPU in X-Plane.
@Ben: Could you tell us limitations about overclooking (CPU/RAM/GPU/) OPENGL (code goes crazy) ?
Greets
John
I view overclocking as similar to telling my five year old to “go faster” – he may go faster and get things done quicker but at some point he will exceed his limits, trip over his own legs, and face plant. 🙂 . The problem is…where _is_ that limit?
https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35923
The issue here is that the rules for how machine code is interpreted by the CPU go out the window if the CPU is overclocked past a certain point.
Now, not every crash is caused by OC – in fact, lots of them aren’t – but if you are OC and the sim seems randomly unstable, turning the clocks back down to ‘normal’ is a cheap way to eliminate something that really needs to be eliminated; if your sim is crashing randomly, no trouble shooting of versions or add-ons or drivers is going to help.
I had an AMD CPU once, one of the first 64bit ones, and it crashed in games a lot. It was configured up to spec, but in the end I was only able to stabilise the PC by underclocking the memory speed. There are tools to test if your overclock is stable. This is useful even if you don’t have overclocked your PC. There might be faulty hardware, or hardware that doesn’t meet spec, or thermal issues.
Also, an unstable or underpowered PSU (power supply) is also a possibility. Lots of people buy a PC, and then upgrade to better GPU, CPU, more drives without adding all these consumers up to check if the PSU is up to the job.
Never ever settle with a cheap power supply. It might destroy your hardware and smell bad while doing so.
Great update! I have flown three flights now, two third party (REP 172 and ZIbo) with flags about the “Experimental Mode”, and absolutely no problems. You guys are the best! Thanks.
Honestly that is kind of sad comment, reflecting our common past experience. Users now actually thanks Laminar for releasing minor update, which actually doesn’t break anything! So instead having this as standard it now deserves compliment. Huh. 🙁
Vulcan Beta by Xmas 2020. Or otherwise hair is trimmed.
Hair will be trimmed because Vulcans only exist in Sci-Fi.
Now that 11.40 has been released, are there any new stuff in the experimental flightmodel or is it the same right now?
I don’t think I understand the question. Do you mean: does Austin have new experimental FM work that he coded after 11.40 that isn’t release yet?
If I may – and I’m a frequent flyer on this topic 😉 – I think that I’m still _somewhat_ wondering too. Then again, maybe I’m suffering from soft memory.
We still have the option for the experimental flight model in X-Plane. Given. The extensive videos Austin produced were very informative regarding the flight model. I think the question that some users may have is this: just what was improved, the default flight model, the experimental flight model, or both?
In the future, will we always have the experimental flight model option, and will well-tested elements of the XFM slowly trickle into the default? I suppose this question can have a very grey-area answer, but I thought I’d ask it anyway.
Looking forward to 11.50 just like everyone else, but I also trust that we will not get it until its safely ready for us to get it. Really appreciate the sharing of your development methods. I too like to housekeep along with new code creation.
The 11.40 notes and Austin’s videos cover what is in 11.40 both experimental and not. In the future, what is experimental now will be _the_ flight model.
My guess is that we will then start a _new_ experimental FM for what Austin comes up next. The idea is to have a sort of a “long open beta” for the FM that isn’t tied to sim releases so that authors have time to use the experimental FM, which can take months, not weeks.
It also lets people using X-plane for real engineering design work get access to our very best physics immediately.
The problem with the clarity of this message is that theres no clear distinction between Current flight model, Next-Gen, and Experimental. I think you’re saying the current labeled ‘Experimental’ model is in fact locked down as the Next-Gen model. Which closes off Austins ability to deliver ‘as he likes’ changes (wait, wheres the leash?) – or changes screw over aircraft devs (because experimental == it will change!)
Wait – current and previously supported FMs are always clearly defined. What I’m saying is: what we shipped as experimental in 11.40 – we’re pretty happy with it – it’s to a point where it would make a sense to ‘cut it off’ and make a specific versioned FM out of it (e.g. what you get with future backward compatibility if experimental FM is off).
The instant we do that, Austin can immediately start doing NEW experimental features that will remain experimental for a longer time because they’re not tested yet.
Think of it like noodles coming out of one of those mechanical noodle extruders. You put the dough in and turn it and noodle starts coming out. That’s the experimental FM … it’s growing as it comes out of the machine in real time.
Then when you have enoguh noodly goodness, you take a knife and cut off what you have so far, and throw that in a pot to cook. That’s a version of the FM. At that instant you can keep turning the crank and extruding more noodles…that’ll be the NEXT batch. It’s just a question of deciding when is a good time to make a cut and have something well defined that can be supported stably.
My take-away from 11.40 is that what we tested now as experimental in 11.40 is ready to be cut off when we can get to it, because it’s pretty solid.
Ben, I think Austin needs version numbers for his noodles.
That way if we know which version is default, which version is experimental, and which version is still just a lump of dough, then we’ll have clarity. Comments about specific cool new things could be tagged with the appropriate version number, creating the clarity that I think Nathan is looking for. Me too. This avoids potential issues of semantics, especially for non-English speakers.
I prefer my flight models al dente, please. 😉
I hope the current experimental flight model is not ready for release. Canard aircraft are currently ruined, the canards stall prematurely and dive the aircraft at speed well above correct canard stall speeds. Austin is aware.
I’m just worried Austin cant push his next noodle out until 3rd parties have finished cooking with the first noodle. And at what point do they start cooking? The public don’t want uncooked noodles, and bet Austin wants to put gnocchi in at the 9 minute mark.
No, no third party dependency.
Hi Ben and Team,
I’m sure this is your favorite topic /s…. [begin elevator pitch] I’m great at crashing software (when it’s valuable of course) and writing thoughtful, detailed bug reports, without exclamation marks or caps lock. Bug reports packed with reproducibility details and zero opinions, free of anxiety and ambiguous pronouns like “it”. I’ll get you to that offending line of code so you can go back to enjoying your holiday egg nog.
If you need some hardware diversity for your private beta and all of the above, i’m ready and willing to core dump on short final.
iMac Pro, iMacPro1,1, 8-Core Intel Xeon W, Radeon Pro Vega 56 8 GB, Catalina 10.15.1 (19B88)
Can you please shed a little light on the outstanding whole-of-fame known issues that keep a static top presence with every recent release:
XPD-7871 Dark contrails instead of white.
XPD-9388 Software hangs upon exit when using VR.
XPD-9501, XPD-9449 AMD driver bugs with displays & weapons.
XPD-9729 Contrails and wing condensation missing in replay.
what is really putting back the permanent iron-out or fix for these?
Thanks
very good question – maybe contrails look better with Vulkan now
… the software hangs upon exit when using VR for me are gone with Oculus Rift and Rift S since NVIDIA has updated their drivers (around 9 month ago)
Hello,
Starting couple days ago I cannot enable 3D mouse to work in Steam VR, even after selecting the option in VR Hardware. Any suggestions?
Thank you.
Try to assign a key or a joystick button to “enable mouse on/off” (or something similar). It works during the fly.
BUT not in the hangar, when you see options menu. In this case, I usually go from no-VR to VR and mantain the mouse in the center of the screen and cross my fingers… If mouse didn’t appear in VR, I change again to non-VR and again to VR…
Regards
Tried the way you explained but the mouse still doesn’t show up to me in hangar.
Have anyone been able to bring back the mouse cursor?
Enjoy your mobile release. I’m sure no is happier than you guys. I’m sure about that. My clouds are ugly in x plane 11 desktop any solution?
Quick question on XPD-10396 (Fixed mic permissions on Mac)…
Was this the issue with MacOS 10.14 (Mojave) and 10.15 (Catalina) with microphone access? I’ve read elsewhere that a certain plugin that requires microphone access couldn’t work with X-Plane under MacOS 10.14 or MacOS 10.15 because X-Plane itself wasn’t code-signed with audio capture entitlement on the MacOS platform. I just wasn’t sure if XPD-10396 was this issue or a different one.
And Ben, thank you for taking the time to keep the community in the loop. I, along with so many others, really appreciate your (and the whole team’s) time and effort.
Yes – this is that issue, and should resolve problems for plugins like XSB (although it is not the only one I heard about) that have audio services _inside_ the plugin and not in a separate helper app.
The issue is that in 11.36 we didn’t have any security entitlements set at all, so the OS assumed that we _might_ ask for anything and would ask the user for mic access when a plugin opened an audio source.
In 11.40 we list a bunch of entitlements explicitly (E.g. code-gen execution so Lua plugins can work) and we left the mic off. Having “actively omitted it” from a positive list of security entitlements, the OS interprets that as “those LR guys say they DO NOT need the mic, so if x-plane asks for the mic, it’s infected by spyware, just deny it”. No user prompt.
In 11.41 we added the mic entitlement to our list, hopefully fixing the issue. Only X-Plane could fix this – plugin DLLs don’t get security entitlements, as it’s on the process level.
With the switch to Vulcan, is more modern texture compression supported?
BC1 is ancient; ASTC gives much better quality even at 8×6 with 2.67 bits per pixel.
Color banding and block artifacts are very noticeable with BC1, especially in darker areas such as baked AO.
I’d love that a lot, unfortunately the thing stopping us here isn’t OpenGL but hardware support. If you take a look at the Vulkan hardware database, you can take a see what features are supported by what hardware: https://vulkan.gpuinfo.org/listfeatures.php
ASTC is supported on just 21% of hardware, the majority of which is mobile hardware. Intel integrated GPUs seem to support it as well, but that’s it. No AMD or Nvidia support for ASTC, except for the mobile Nvidia Tegra chips. It’s even worse when it comes to support of ETC compression. As it stands, BC is supported ubiquitously on Desktop. Plus there is the whole problem of fast compression, which is relevant for third party authors as well as us trying to do it at runtime. That being said, looking at the more modern versions of BC might be worth it, since hardware support for those does exist.
Both BC6H and BC7 are very good, usually indistinguishable from ground truth, albeit with twice the VRAM usage.
Any news on the spring action nose wheel for all other aircraft besides the C172? It seems to work really good.
Uh, most aircraft _don’t_ have this mechanical feature. I don’t think any other aircraft in our fleet have this hardware, so it doesn’t make sense to turn it on everywhere.
Oh, I might have misunderstood the idea then. I thought that it was going to be a set of new mechanics available to everyone, via checkbox and configurable parameters on Plane Maker, and that C172 was just a test.
So 3rd parties still need to code it by their own to replicate that behavior?
No – when the experimental FM becomes the official one, all aircraft saved in the latest version of Plane-Maker will use that version.
Hello,
hope I good understand again, it’s only C172 system and then no other aircraft need this feature. I must say, I returned to previous C172 because I don’t like that spring system on nose gear. In other side, is possibility to disable this feature on now C172 version?
Yes – you can edit the aircraft and modify it in Plane-Maker. It’s a landing gear setting.
The bungee steering *is* an option selectable in PM on a per aircraft base.
Its acitve when the “castor limit” parameter in the Gear Data tab is non-zero and larger than the “n-w steering” in the Gear Loc tab.
Ben, Michael,
thnx gentlemans for info…
I wish User-interface update comes to plane maker and airfoil maker
With December coming closer to an end with Christmas, can you confirm if a beta of Metal and Vulcan will come out before 2020?
We are still aiming for this year! There’s not much left of it. 😐
sounds good, I am interested to see what Mac performance will be like, both initially and over time
thanks
It looks like 11.41r1 went final and wondered if that is true?
If true then will 11.50 be next?
Thanks Bill
Yes and yes.
Is the mouse pointer missing on hangar and game a X-Plane Version problem, or is it a SteamVR Beta Problem?
Hi,
Can the sky banding / dome be fixed ?
Hi,
after a long time flying turbines and twins I jumped into the ASG29 Glider. The weather was good for ridge gliding in my local area. 260-270 degrees with 25-30 ktn. I knew the race track from real and flew it douzens times.
What you done with the wind engine in X-Plane is HUGE WORK ! Lift and drag. All parts of the flight where exactly what I knew from real. The heights, lift and drags at different sections at the ridge are the same like in real. And also the very tricky sections was highly accurate. And what could I say sweating…the last miles. I finished after 1:58H and over 200km.
I used ORTHO4XP and mesh at ZL19.
I think this is the best test to see how X-Plane perform !
I used X-Plane now for over 4 Year’s but that day yesterday was mind blowing in case of weather dynamics acting in X-Plane.
Greets
John
This small correction on particle.glsl could fix the dark contrails issue 😉
v_color.rgb *= 3;
v_color.a *= .75;