X-Plane 11.50b14 Now Available

110 comments on “X-Plane 11.50b14 Now Available”

1. Rubberbanding, frametime issue with latest Nvidia drivers are still there for me. I have tried 451.48 and 451.67. Went back to 446.14.

   i7-6700hq
   gtx 1060

   1. File a bug please.

2. Thanks for the detailed update notes and blog.

   I reported the issues with the NVIDIA 451.48 drivers to NVIDIA, both on its forums and through its feedback form. Did NVIDIA acknowledge the issue? I’m currently on the prior driver version and I’m hesitant to update unless it’s clear that it’s fixed.

   If we experience a crash, is there anything we can interrogate ourselves to identify a potential plugin issue or is it beyond the ability of the end user?

   Great work on the betas – it’s getting better every release.

3. Hey,
   I filed a bug report in B13 – XPD10916 – which in the B14 release notes shows as fixed but I still have the same issue. Do I file another bug report?

   1. Yeah – if a bug was noted as fixed in an XPD and you still see it, please file a new bug – if you reference the existing bug number that’s useful in sorting out what happened.

4. Reporto problemas con beta 14. En modo Full Screen baja a la mitad los FPS. En modo ventana funcionan normal. RX570

   1. In english:
      I report b14 problems. In Full Screen mode the FPS drop to half. In windowed mode works fine. RX750

      1. I also have the same problem, it will recover if the vertical synchronized is turned off in graphic setup.

5. Would it be possible to write a log entry with the plugin using the bad call
   before you crash the sim ?

   I am sure that many users will have old plugins and never know that
   they need updates and the crash times will now lower in future.

   1. I concur – crashing a plugin (mine, for one) that has never crashed before, just to prove a point, is rather lame. And then letting your player base discover it via crashes, and hopefully eventually trickle that issue to the right developers to find what happened on their own, is just annoying, to say the least. And then releasing a blog post about what you did, significantly after releasing the beta to the public, would’ve really only been helpful, beforehand.

      possible lessons for next time: Log the issue, maybe warn via patch notes about what you did, allow alpha copy of the release to plugin devs before the masses, attempt to contact them when you get crash reports, when possible.

      We make plugins to enhance YOUR CUSTOMERS’ experience with YOUR product.
      Suddenly having THEM be forced to deal with a previously working (but non-thread-safe) plugin Window API call is really uncalled for.

      1. Your premise is wrong. “Crashing a plugin that has never crashed before.” The only plugins that crash due to this mod are ones that call the XPLM on a worker thread. And every time you call the XPLM on a worker thread, you are shooting a bullet into x-plane and hoping you don’t hit its heart. NOTHING in the SDK code path is synchronized. There are no locks, no atomics. You are closing your eyes and driving through the intersection with no checking of whether the traffic light is red or green.

         The SDK API was never “not thread safe but previously working.” It was “not thread safe, but crashing in a site far enough from the plugin who is violating the API and doing the damage that the author _thinks_ it is someone else’s fault. These crashes are incredibly hard to debug or attribute because they result in the book keeping inside X-Plane getting totally corrupted, which results in a very wide distribution of “impossible” errors that would not happen if the code were not being called concurrently.

         Here is the subset of APIs of the XPLM that contain known race conditions – these are things that will crash the sim if called – with statistical probability – meaning Not 100% of the time, but yes if called enough times.
         1. Anything that creates, deletes, or uses an XPLM resource.
         2. Anything that causes another plugin (including the XPLM to be dispatched).
         That is … almost the entire API. As far as I know, the only XPLM APIs that you can call that don’t contain crash-containing data races are, maybe:
         – Getting the XPLM API version.
         – Getting your own plugin ID – the result will be wrong, but I think there’s a chance it might be safe, I guess?
         – I think the logging API might not crash.
         Of these, I have only put a hard crash on threaded use of a small subset of one of these – the APIs that talk DIRECTLY to our window management layer and therefore are going into Vulkan code with no locks.

         1. I’m not an X-Plane plugin developer, but the logging API definitely should be thread-safe! Some time ago I wrote some multi-thresded C program. Ehen trying to debug I used fprintf() to write messages into a log file. The chronology was quite a mess, so I wrote my own thread logging: Basically it still uses fprintf() to write messages into a log file, but only in ONE logging thread that reads messages to log from an UDP socket. The writing threads basically just send() to the socket. The kernel serislizes the messsges on the socket. Kind of primitive, but working well. I even can collect the first messages in a memory buffer until the log file and log level are set up…

6. I’m on an iMac 2017 27” with à Radeon Pro 570 (4GB). All through the beta run I have perceived that I’m getting significantly better frame rates with Metal activated, but with beta 13 and 14 it seems like I’m getting better frame rates without Metal, at least when the sky is cloudy. Can this be true? Anything I can do to provide proof of this, or are you aware?

   Clouds are generally a performance sink for me. Is this being addressed at all?

   On a side note I have noticed that the slider for preset of weather sometimes changes on its own. I change to e.g. broken from overcast, and sometimes it reverts back whilst in the sim.

   1. Forget about this, they will never fix it ever. They will tell you to upgrade your iMac and if you upgrade your iMac you will still have the same issue forever. X-Plane only cares about physics but they are making a flight simulator that can’t run fine near to cloud and they don’t care, try to fly near the Asphalt or Water 😀 😀

      1. How did this pass the moderation again?

7. Hi,
   I filed a bug regarding the _bump mapping_ being _reversed_ on aircraft objs.
   Is that just me or is this a bug you guys are seeing too?

   1. This was not reproducible on our end so far.

      1. Too bad..
         Happens for me since beta 11, I think.
         But only using vulkan..

         Thanks

8. With this version, starting a flight is stuck on ‘Finishing asynchronous loading”, the last thing in the log was loading the Cessna 172SP. Tried starting a flight with a different aircraft and still get the same problem.

9. Hi, just tested on new driver and it works fine 🙂

10. Tested with latest Nvidia drivers and appears to have fixed the rubber banding for me as well on a 2070 Super

11. well B14 has killed off any fps gains we have had up till now with Vulkan i am now getting exactly the same fps with 11.41 as i am with B14 it seems we are taking 1 stepo forward and 2 back , i have not updated to the latest nvidia driver

12. Hi,
    I’m the developer of AviTab so here are my contact details if you need them.

    AviTab makes heavy use of multithreading, but should be well-behaved.

    There were two rare crash bugs in AviTab’s history, but they are both fixed in the latest version (0.3.18).

    There are two crash bugs remaining that I am already aware of:

    1) The current beta (!) release (0.3.19) crashes when disabling and then enabling it in the plugin manager, this will be fixed soon and I don’t need further information.

    2) About 10% of the users report a crash that happens immediately when starting X-Plane. This only occurs since the latest Windows update (2004) and even happens on 11.43. So far I have no idea what this could be since I can’t reproduce it at all. So if you have any backtrace, please send it to me.

13. Still stutters with Vulkan, despite also the new driver released by Nvidia… what a pity

    1. In 451.48: Ugh !! … Will it be Microsoft’s hardware acceleration in win 10 2004 … or is it your “fault” …? Laminar Research…!!!!. He continues to micro stutter constantly: TOO BAD!

       1. I agree.. Right now I hope in the future betas… In the meantime I’m forced to use OpenGL because with Vulkan, as far as I’m concerned, the simulator is absolutely unusable! -.-

14. Head movement is not smooth and is very stuttery in VR. lots of screen tearing too, almost as if the sim cant keep up with me. B9 to B11 was very good in VR. 13 plus has killed it.

15. Hi,
    I would like to know about amd graphics on linux (using opensuse 15.1 with xorg:mesa repository). Is there some change like blocking or else, because since beta9, x-plane(vulkan) crashes on startup. Nor previous nor latest drivers allows to run x-plane. Mostly it generates crash-report, so once per beta10,11,12,14 sent. Don`t have problems with other games.
    ….
    0:00:00.000 I/VK: maxImageCount 3:
    0:00:00.000 I/VK: supportedUsageFlags 1f:
    0:00:00.000 I/GFX/VK: Created swapchain for 0x51f6da0 with size { 2560x1080x3 } <<<< random numbering
    –=={This application has crashed!}==–

    1. Have you tried setting ‘Use vsync’, quitting and only the next time switching on Vulkan? Worked fine here with AMD/Linux/mesa. As soon as I switch vsync off, X-Plane crashes with ‘I/GFX/VK: Created swapchain’

       1. Already tried… but doesn`t helped 🙁

16. Will Vulkan allow the BLEND_GLASS directive to become available to scenery OBJs? Scenery developers could really use that feature for rendering glass correctly.

    1. No. That’s driven by a change to the rendering engine that we intend to make at some point, but it’s unrelated to VUlkan.

17. Finally seeing what is possible … 50 FPS and very smooth with latest Nvidia drivers and stutters are gone…. is there an embarrassing gotcha you guys dealt with? There has to be… differences between b11 and 13/14 are too drastic on my hardware 🙂

    Thank you!

    1. The surging FPS with the new NV driver and b13 (should be fixed in b14, if it’s not, file a bug) was caused by us trusting the driver to block if the CPU got too far ahead of the GPU. The spec does not guarantee this – it may happen but is not guarnateed to happen. So it looks to me like NV stopped blocking and as a result the sim would race WAY ahead of the driver and kind of anarchy would eventually result. We put in our own block for drivers that don’t, which is the correct thing. We were onyl surprised in that we’ve been coding for Vulkan for at least two years now in the alb and this is the frist driver that didn’t blcock when the CPU got aehad.

       1. 🙂 Thanks Ben!

       2. Hi Ben,

          From a completely naive viewpoint – that sounds like the GPU and/or GPU driver is a bottleneck if the CPU can get ahead. Is that the case?

          I’ve always been under the understanding that the CPU was the bottleneck, X-Plane being more CPU bound than it is GPU bound, in particular due to single-core frequencies.

          I’m asking purely out of curiosity.

          Cheers,
          Craig

          1. In the cases we saw with surging the GPU (the actual chip, not the driver on the CPU) was the bottleneck – this happens sometimes – the Vulkan driver is VERY fast and you can have a big monitor and get bound up on fill rate. It’s not something that happened as much before Vulkan, but Vulkan really offloaded the CPU a lot.

             1. Thanks for taking the time to educate.

       3. Hello,

          So what to do?
          Since B11 there was a surge or drop of FPS in heavily built-up areas, meaning when changing the view FPS drops to 12-17FPS and recovers to 50FPS 2 to 10 seconds later. Is my hardware faulty?

          Thanks, Dan

18. Could you go ahead and release the updated airport bundle as a separate update? It is held captive, if you will, by the 11.50 update. The updated bundle seems to have been ready for a while now, and I would rather not download the airports one by one from the scenery gateway. Thanks!

    1. We would like to someday do that but we don’t have the technical infrastructure for it right now.

19. Are flickering/flashing white terrain areas near the horizon a known bug on Linux+Nvidia? I have video of the issue if you would like to see it.

    1. I am also seeing this on Windows.

20. tolis a319 still have screen flickering since day one when using betas

    1. That is a known Addon issue, ToLiss needs to update it for it to work properly, according to the 11.50 release notes.

21. I cant revert back to b13 on Steam. Steam ‘stable beta’ is giving me b14, not b13.

    Any ideas folks?

    b14 is definitely not performing well for me. I’ve tried both nVidia drivers.

    1. This is intentional. Beta 14 is the current beta. Stable/unstable is not meant to let you use arbitrary old betas. It’s just there so we don’t ship a crashing beta to everyone.

    2. copy thank Ben.

       Im experiencing minor but very frequent rubber-banding causing momentary stutters . ill submit a log.txt

       Im on nV driver 26.21.14.4614 as 451.67 is not stable.

22. Why do you make Xplane crash instead of prevent it from happen, just catching the error and writing a warning in the log?

    1. Once we hit this point we can’t proceed. The plugin is, for example, trying to make a new window. We _always_ make a new window – there’s no condition in which we return “sorry, no window”. So if we return null (no window) the plugin is going to crash pretty much instantly. We can’t make the window, that crashes us.

       In the end of the day, if a plugin does something that it is not supposed to do, that is in violation of the API and that can crash the sim, the options are (1) fix the plugin or (2) remove the plugin.

       Plugins are C++ running in our process – they don’t live in a padded room, and we cannot stop them from taking down x-plane.

       The advantage of what we have done is that we get extremely _clear_ crashes, instead of _incomprehensible_ crashes. So we have a good chance that we can find the plugin author and tell them to stop. In the future we can name them in the log, which will help even more.

       What we had before we did this was the plugin would either (1) crash inside the plugin, where we can’t see what’s going on because we don’t have their code or (2) crash deep inside x-plane in a way that made no sense. The “new” crashes we see with this logging have been in x-plane for _years_, but they have existed as a background radiation of “x-plane just randomly doesn’t work and no one knows why”. Now we are going to know why.

       If we just logged the error and returned to the plugin, the crash would be mysterious like we had before, and we wouldn’t make progress.

       1. But logging and then crashing would be an alternative for
          help users deactivate or update old plugins. There are
          plugins in the wild that maybe never get updated.

          A log message like “Plugin xyz is causing a crash by doing silly thing abc and we can’t recover this”

          1. I totally agree. As soon as we _can_ get the plugin information into the log we will — third parties asked for the same thing.

             The problem is that
             (1) the logging system for plugins that we use to name plugins that crash on the main thread…isn’t thread safe – just like the rest of the SDK – so we have to _build_ a new thing and
             (2) it’s REALLY late in the beta, so we can’t build a new thing.

             So we’ll get the logging of the plugin name in as soon as we can, but it’s not going to be 11.50.

             In the meantime, we do get a good trace in the auto report so we can tell plugin authors directly, and plugin authors who are _developing_ their add-on will get a crash that is much easier for them to understand too.

             1. For XTLua I push_back() debug strings on a vector from the thread then loop through them calling xplmdebug and clear on the flight loop.
                recent addition because windows users cant see printf output.

                744 systems are now all on xtlua with 500uS frametime consumption according to the fantastic new plugin admin.

       2. I for one, am seeing errors with UltraWeatherXP in the log just prior to the crash, saying it is trying to do something illegal (create a new window)…. are you guys informing developers as you find these items?

          1. Yes, when we can – we’ve reached out to the top six plugins that we see crash by frequency so far, and we’ll keep combing the reports – as long as only we can see who crashed (which is _not_ at all ideal, but is what we have for the short term given time constraints) it’s definitely on us to share that info and not just let everyone suffer in the dark.

             With that in mind, there is no guarantee that consecutive in the log means the log message is related to the crash. Since these issues are all multi-threading issues, by definition the thing crashing is running in the background.

             If you find a 100% correlation and removing the plugin with the message fixes it and the function in the plugin _never_ works, that’s reasonably good circumstantial evidence – either way you can tell the plugin author that “function X crashes with 11.50b14 100% of the time” – the plugin author could then try it….if they are in a debugger, they’ll see in the debugger that their call was the cause.

       3. Thank you for the explanation.

          A good plugin (and any good program) should check for null-pointers, but it’s obvious that’s out of your control.

          If the plugins would run in a separate thread (or process), it would be possible to kill the thread instantly and then X-Plane could deactivate the offending plugin and not crash.

          I don’t guess that would involve much work to move them to separate threads/processes, maybe a important thing for the 11.51?

          Crashes in the middle of a long flight cause always bad desires against the X-Plane development team, independently of who causes the root error 🙂

          1. Wait – I don’t agree with “a good plugin should check for null pointers”. That is true if the API is _allowed_ to return null pointers. So e.g. if you call XPLMFindDataRef and don’t check for null, that’s a plugin bug – finding can fail! But XPLMCreateWindowEx, for example, _always_ creates a new window. It has no failure modes that don’t also result in the complete failure of the sim (because it basically only fails if you run your machine out of virtual memory – if this seems ‘sloppy’ to you, I strongly recommend Herb Sutter’s talk on making memory exhaustion not a runtime error from last year’s cppcon – it’s eye opening!) so a plugin has no need to check for null and _no reasonable action_ should null occur.

             Regarding killing, we must distinguish thread vs process! In C++ you cannot safely kill a thread – if that thread has a mutex held, the program will deadlock; if the mutex is held and you release it, the data structure it was protecting may be inconsistent…Raymond Chen had a good post once on OldNewThing about how KillThread is basically an API you can never use.

             If plugins were in another -process-, that would be a different story, and that’s actually something that long term, I’d like to see happen. (And when we get there, I’ll get a massive “I told you so” from Philipp, who did an add-on across processes around a decade ago.).

             Moving to another process requires moving to another thread (because the main thread is in our process) and that is non-trivial – right now plugins get data back synchronously (while the sim waits) – in another process, the APIs would have to be redesigned to be asynchronous and plugins rewritten to cope with this. It’s a good place to go long term, but it is big and long term and some use cases don’t fit well with it.

             I totally agree that crashes are bad for users – I view the flight ending prematurely as similar to a “data loss” bug in a document editing program – the worst thing you can have for a bug outcome.

             When we get to RC we may be able to turn _some_ of the hard crashes into silent returns – but not all of them – it will depend on the API, and I fear that the plugins calling some APIs are probably calling a lot of them.

             The good news is we have gotten immediate and very helpful responses from the plugin authors we’ve reached out to.

23. Best one yet, even with my dated hardware. I was between 95/100 FPS as I approached KHSP rw 7 on RNAV a few minutes ago. Lots of mountains, pretty high winds, but no problems whatsoever! Thanks to all.

24. After not being able to crash b13, I had a freeze last night in b14. No CTD auto-report form offered and nothing I could spot in the log.txt. I had to close the X-system in Windows task manager. I was running some popular plugins (Zibo, ASXP, xPilot, Navigraph Simlink) and around a minute before the ‘freeze’ Simlink lost contact with XP11 and would not reconnect. When the sim crash occurred the visuals simply froze, but sound continued and xPilot must have still been running as it eventually kicked me out for <20 fps. I was running the latest game-ready NV driver with HAGS enabled. The changes I'd made since successful flights in b13 were NV driver update from 446.14, enable HAGS, and tweak AA up from 2x to 4x

25. 11.50b14 works fine on my system with the latest NVidia driver.
    But the scenery shadow draw distance in 11.50bxx is very low compared to 11.41.
    Will that be fixed?

    1. The _interior_ cockpit draw distance is too short – this is a known bug. The _exterior_ draw distance is short by design to keep the shadows from looking ugly – it’s a trade-off between quality and quantity. The exterior decision is the intentional one.

26. Hi Ben, a massive thank you to everyone there for their hard work. Beta 14 has been impressive. For the first time ever i’m getting a huge frame improvement anywhere between a stable 40-60 in urban area’s and up to 70-90 in non urban areas depending on the settings, without even needing a auto lod script. For the beta’s i haven’t tried any 3rd party plugins yet, only custom scenery packs/ortho’s and purchased aircraft. The shadows still need some work but they are a lot better.

    One thing that could really help is the ability to set some of the world objects individually. All i’d like to see is a slider for traffic, buildings, and trees as like a sub section of world objects. I’m using a mix of ortho’s and the tree placements are a nightmare. I’d just like the ability in the graphics settings tabs to be able to adjust these so i could run for example, low level of trees, medium level of buildings, and maybe a medium or higher level and traffic without having to muck around with lua scripts or wed. Could you guys please consider it? If you put the anisotropic filter in surely you could make some other basic options available.

    1. I’m sorry, but we’re not going to do that. It is definitely _not_ a goal for the rendering settings to solve the problem of scenery looking weird by letting you pick out individual parts of the scenery.

       If you really just want a certain type of object gone, you can make a scenery pack in WED that is just a big exclusion zone for a certain type of element and drop it into your custom scenery. I don’t know if you can make an exclusion zone bigger than a single DSF (you should be able to – if it doesn’t break it up for you, that’d be a WED bug).

       The anisotropic filtering slider was a one-time freebie because everyone had access to it by the NV/AMD control panels until we moved to Vulkan.

       1. Ben, you are missing the point.

          With orthos and also with openstreetmap derived scenery, we can now see a disconnect between where scenery SHOULD and should NOT be. Autogen buildings are more or less aligned with roads and cities, but autogen trees are randomly placed outside of cities. Thus we can see trees in lakes and in rivers where they should NOT be. Therefore it is preferable to have some control over whether to draw autogen trees or not.

          Giving the user more control is a good thing. As a developer it can be scary to do, but it pays off in the long run.

          1. I think I might be _disagreeing_ about the point, not missing it. :-). But maybe not.

             There are two cases I can imagine here:
             1. The scenery pack in question is a _single_ scenery pack (or set of packs) from one provider that, for some reason, when installed as intended, has trees in the wrong place a user wants to delete or
             2. The user is using more than one scenery source from multiple providers, that, when layered and combined, produce clashes (e.g. the trees from one don’t match the others from the other).

             My statement about making an overlay rather than providing a slider was meant to address the second situation…my view is that once you have two packs that don’t play nicely together, there’s just no set of _rendering options_ that’s going to be a really good general purpose way to fix this conflict. It’s an “if all you’ve got is a hammer” kind of situation…exclusion zones are custom built to zap things that shouldn’t be there — rendering settings are carpet bombing.

             1. Carpet bombing worked quite well in X-Plane 10 🙂
                To fix the problem now, we have to enter where the dragons live in, settings.txt and without the protection of a simple slider.
                Steven.

27. X-Plane 11.50 beta 14 and Nvidia driver 451.67 now seem to be a good team – all rubberbanding problems are gone.

    Regards
    Marc Westhofen
    ———-
    CPU: Intel Core i7 9800X (OC 8x 4.8GHz) // CPU Cooling: NZXT KRAKEN X72 // Main Board: ASUS TUF X299 MARK 1 // Graphics Card: GeForce RTX 2080 Ti ROG STRIX O11G // RAM: 32GB (G.Skill Trident Z RGB Series, DDR4-3000, CL 15, quad channel) // Hard Drive: Samsung 970 EVO NVMe SSD 1TB, PCIe 3.0 (M.2) // Optical Drive: LG BH16NS55 // Power Supply: Corsair HX850 High Performance // Head Tracker: Track IR 5 // Mouse: Logitech G203 // Joystick: Thrustmaster T.Flight Hotas Stick X // Keyboard: Logitech G815 (tactile) // Monitor: LG 27UL850-W (3840×2160) + LG FLATRON IPS235 (1920×1080) // OS: Windows 10 Pro 64bit //

28. Please please please fix the shimmering! The taxi lines are like crawling ants.

29. Using iMac27 2019 and XP15b14 with and without Metal (after restart) and I see no differed fps. Moreover there is no difference to XP11.41r1version that I am testing parallel ! Unfortunately while running under Metal a significant flickering occurs from time to time (sending bug report)..

    1. Using Windows 10, and Nvidia last driver. I have the same problem… no any difference more now with Vulkan or not !!
       Was ok on b13. A big backward step done with b14.
       (France)

30. NVidia 451.67:
    Encountered Vulkan device loss error!
    X-Plane cannot continue and will now quit.
    vkQueueSubmit(m_queue, 1, &info, fence)…
    entered a cloud…and stuttering always

    1. We return, the community of colleagues, to OpenGL. Now it correctly reads dsf and my TolissA321 and FFA350 are working properly.
       Vulkan … shit … Ah! and without clouds or cirrus clouds, also in OpenGL … What a mess !!

31. 11.50b14 X-Plane just dies with a vulcan error. Modal dialog says to fillout auto report but on dismissing dialog X-Plane goes the way of the dodo. Anyway to force it to send the bug report?

32. The cloud issue has been there for years and you don’t care. How can you make a flight simulator that can’t get near the cloud 😀 😀 And you know, you will keep ignoring this forever because you don’t respect your users. I will never support X-Plane again until they respect us.

    1. respect is a two way thing …

       1. One of them will be the one that many of us take, leaving X Plane forever

          1. Bye now. Thanks for participating in this beta program. Your constructive feedback has been an inspiration to all of us.

          2. I’m really amazed at how many people are unhappy with the whole simulator here during version 11.50 beta (and I mean all things in the simulator). This is a beta run – and if we submit bug reports and write here in the blog, it should be to help LR make this beta version the next full release version.
             Remember that now – This is a beta run!

             1. I don’t think is about this beta. I think is about what’s coming next. I enjoyed a lot XP11, and 10 too, but after 900 hours between them, I feel the sim outdated.

                It has a great ground handling and flight model, if not the best one. But is lacking all other things like AI, ATC, good default weather, good scenery (I understand that satellite or photogrammetry can be too much for XP, but there are other ways of making the default scenery look much better…). I summary, I think is missing immersion.

                Of course changes had to be made under the hood before improving anything, but now that those changes are being been made, I think some people want to know what’s coming next, and how XP is going to be more like a 2020 sim/game than a 2010 one.

                Because this beta is what it is, I don’t think anyone expected this beta to convert XP11 in a complete new sim visually.

       2. Sure, I already respected them first by purchasing licenses for version 10 and 11 instead of using them cracked. And respected them when I reported all issues I have, then respected them again when I used their every beta to fix their broken simulator. Respected them when I was patient for years and waiting for them to fix ATC, cloud issues, FPS issues, random crash issues, Mac version issues and they simply don’t care.

          1. Hi,

             We _do_ actually care. Right now if you look at the current activity going on inside the company, it includes ATC fixes, work on clouds, fixing a ton of crashes, and over half the staff uses Mac as their primary dev machine.

             There is a huge latency between when we code things and when they make it into the product for some features, and I fully realize that only _shipping_ these changes counts for anything. But I felt like I have to say something here. We’re not sitting around going “everything is fine as is, let’s not write any more code.”

             What we don’t have time to do is jump into these posts and address every single comment users leave. I’ve been pretty loose about letting people comment on almost anything (“I have this hardware and I see this weird thing when I do this”) but we don’t even have time to write individual responses to the bug reports, let alone the blog comments.

             1. But in any version I could modify the cloud settings I could gain about 50% frame rate on my lower-end GPU. Why not allow manual override while sutomazic tuning does not work well enough?

             2. I recently commented asking about a road map update with FS Expo being canceled. I think the frustration you are seeing is that what happens after 11.50 isn’t really clear (at least it isn’t to me). I know everything is working hard, but I don’t know what “ATC fixes” means. Is that fixing the lack of terrain awareness and/or actually adding things like VFR operations that Chris mentioned in a blog post back in 2011? I listened to Austin’s interview and I don’t think I gained any clarity of whether we will get additional features/improvements in v11 or if improvements are going to come in a future version. Then of course we have no idea if that is 6 months from now or 2 years from now.
                I hope you give a road map / state of the sim update soon because I don’t think the issue is going to get any better as the 11.50 Beta winds down. As of Beta 14 my sim is stable and after a few flights the Vulkan experience becomes “normal”. Then you start thinking about how everything else looks/feels about the same as 11.30 did back in January 2019.
                With that said, the B14 is working great for me. I’m looking forward to 11.50 wrapping up and what comes next.

             3. You’re right – we don’t have a roadmap out there and due to Expo not happening, we don’t have one _later_ than we would have, in that we would have talked at least a bit in June. I’m not in a position to reveal a bunch of stuff down here now at midnight amongst 80+ comments, but I’m hoping we can start to talk about what’s next once we get Vulkan wound down. Right now we’re just trying to get the beta done – this beta has been a little bit like getting the steak that you get for free if you finish it…we’ve been eating it forever and it’s not a great feeling.

             4. In support of Ben and all the other devs, in the last beta I found a bug related to stutters. I didn’t come on here moaning about it with some vague description, I reported it using the bug reporter, They asked me to send an extra file from the diagnostic reports folder. I got an email back with bug no XPD-10916 allocated and guess what? It’s fixed in beta 14. When your car’s broke you know there’s no point just talking about it on a web forum somewhere. You take it straight to the garage tell them exactly what’s wrong with it and leave it with them until it’s fixed. Please give the guys a chance.

             5. I will eternally burn for laughing at the steak-that-never-ends. You are nearing the number of betas required for the v11.00 release. I don’t remember how many v10 needed… this really does sound like a whole new horse. Take my money!

             6. 10.0 basically needed a full year. When it first came out, there was a bug that caused the new roads to shoot up hundreds of feet in the air like roller coasters. TO DO THIS DAY every time we go by the amusement park on our way from KCLT to Austin’s house, Chris goes “oh look, 10.0!”

          2. LOL

33. Hi,

    I didn’t have enough space to put 11.4 along side with 11.5, so what I did was installed a vanilla 11.5 with no scenery coverage at all.
    Then, created a Symbolic link of Custom Data, Custom Scenery and Global Scenery directories to point to the 11.4 ones. So now I can enjoy all the global scenery custom scenery I worked a lot to fine tune in 11.4.

    It seems to work, but maybe because I’m lucky for now.

    As I see it, Vulkan (11.5) did not change the resources per say. It only changed the way it interacts with the graphic underlying drivers. You didn’t change the representation of objects in your scenery files right ?

    The only thing that might (not sure it will though) cause issues, is that the 11.5 installer will update back these 3 11.4 directories .. (when I’ll upgrade to a newer beta version). But again, this is fine right ? at max I will get more global airports coverage in my 11.4 .. it shouldn’t break 11.4.

    Thanks,
    Doron.

34. X-Plane 11.50b14 is continuously crashing for me. There is no obvious trend as to why this is happening. It’s running around 30-40fps very well. PC that it’s running on is i9 and RX5700XT so I’m assuming it’s not the specs that are the issue. Thought it could be useful feedback for future beta releases. Would love to know some troubleshooting if possible!

35. I installed b14 shortly after it came out (unannounced at that time). I was surprised to see a much more stable situation compared to b13. After reading some mixed experiences with the latest NV drivers I decided to give it a try. I am now at 451.67 and it looks even better as before: no stutters, very smooth run and a steady frame rate. When switching to VR mode it may come near the VRAM limit, but now performs as it should be! Memory management seems to be much better now.

    The graphics settings can be as high as I want them to be (especially Antialising and Anisotropic Filtering) in VR mode, necessary for a high quality image on my HP Reverb headset.

    I hope b15 will further bring the announced performance improvements in VR. This is still an area that will benefit from a good balance in high AA and AF settings and good frame rates.

    Thanks for all the efforts in improving this new release. A major step has been set from b1 to b14 in terms of quality and stability! Vulkan is definitely the way to go!

36. iMac 27″ crash with Killed: -9, no log

    I removed resources/shaders and ran the installer. Any other idea?

37. I see 30-60 FPS. It’s great.
    But still see stuttering during taxing or turning plane to the right/left. I don’t understand it because of good FPS.

    Btw, great beta update. Thanks and keep improving performance please.

    My specs is:
    macOS Catalina, i7-8700B, 32GB RAM, eGPU RX5700XT 8GB VRAM, NVME drive

38. installed the update and sadly the Stutters are killing me, flying over eham or egll all defult scenery at any altm with my spec this shouldn’t happen but its a beta so keep up the good work.

    i7 9700k
    32GB ram
    1080TI
    SSD

    1. Russel. I have very similar specs to you , except I’m i7-8700k
       My system runs at 60+ fps with no stutters in these areas, with all sliders max, and Ortho tiles.
       I would recommend seeking help at the forums or facebook groups.

       1. sorry I should of added im in VR

          Russ

39. One of the things I find helps with the stutters on _my_ system (YMMV) is to use the Oculus Debug Tool and turn off ASW. Of course, this is with an Oculus HMD (Rift S, but also worked with the original Rift + Touch). Some have reported that this helps and others report that it makes it worse, but certainly worth a try. You can turn it back on if it doesn’t help or makes it worse.

    I just hope LR can get to the bottom of those stutters so that I don’t have to turn off ASW each time I start X-Plane.

40. I was having PC reboots in the middle of flights after getting b14. Tracked the problem to the Win.xpl file that came with XPReality Pro Ver 2 update. Norton had even flagged it when I unzipped it. Removing the plug-in fixed the problem. No more re-boots.

    1. Norton flagging it is unrelated to stability issues. The most plausible case is an interaction between the add-on and the sim makes us feed crap into the vulkan driver and the kernel doesn’t recover – which isn’t supposed to happen but…

       Norton’s just going “we don’t see this much or some pattern matching thing fired off.”

41. Thanks guys for your continuous efforts!
    Im running i7 9700
    3.6g
    Rtx 2080

    I was getting stutters on b14 with the latest nvidea driver.
    Went back to 13 and rolled back nvidea as well as g sync not working.
    What is bringing back the stutters?

42. Hi has VR been fully optimized in Beta 14 now or is there still work to be done on it… Just trying to figure if this is as good as its gonna get, Many Thanks

    1. We don’t have any more perf optimization to do, but there’s always the chance there’s still a bug. Sidney’s looking into stutters related to AGP transfers, but in some cases we’ve had users say “it stutters” and when we gather a trace off their system, they’re trying to get X-Plane to just lift way more weight than it could possibly push in VR.

       1. I think that between plugins (which you can’t control and keep warning about) and expecting more “sliders right” than users systems can handle, you are doing great. As I tell my Pastor, you can’t please everybody, but he, like you, keep trying!

       2. As for VR with Rift S…it would be great if LR could fix the hang on exit issue when using VR. It’s a total pain to have to force kill X-Plane every time you exit.

          Also, every time I go to start a flight I end up with my headset going black with an orange LED and the following in the log (and yes becoming is mispelled in your log as it shows below):

          0:02:03.204 E/OVR: Session display lost, becmoing a zombie.
          0:02:03.263 E/VR_BRIDGE: Shutting down hardware because the VR HAL is now in a zombie state.
          0:02:03.466 I/OVR: Shutting Down VR Subsystem.

          At that point I just restart the oculus software and reenable VR and everything works. Working with Jennifer I went back to 11.41 to test…everything works without any issues…then tried OGL on 11.50 and everything works without any issues…but with Vulkan it happens every time. Bug has been filed but never received an XPD number. So do not know if it’s even on anyone’s radar to look into.

          1. I had a similar issue using the Oculus Rift CV1 with an earlier Beta of 11.50. I reported the bug, but LR were unable to reproduce the issue in house. I didn’t have this issue when using a WMR VR headset with any of the 11.50 betas. I didn’t update my 11.41 to the beta, I did a clean install for 11.50. I have always wondered if the Oculus software is treating the two X-Plane installs differently. I haven’t tried the Oculus with the latest beta, I prefer to use the Reverb.

             1. Even in 11.50 it works fine with OGL. I only have the issue when using Vulkan. I’ve done a clean install of the Oculus software just in case something got bunged up there but still have the issue. Once I restart Oculus and enable VR again it all works great. To me, it appears that the Oculus software is crashing during the load of X-Plane and thus X-Plane loses the display and then disables VR. Then I restart Oculus and enable VR and it’s happy. I’ve seen a couple other comments with people having very similar issues but never a peep from LR on ackowledgement, etc. I guess since there’s a workaround it’s not a high priority.

43. Guys,

    I have an i9 iMac with a Vega …48? – I just wanted to say that not only is metal kicking butt and taking names, when I ramp up settings or fly in a scenery heavy area and get 20-30fps, its waaaaaay smoother than earlier versions. I always got the sense that when it was in that range, it was rendering, but not necessarily displaying 20-30fps (like, imagine the frame being delayed and flushed out of the buffer and not making it to the screen…) this might be my imagination, or a result of like some internal time-stepping inside of the airport vehicle animations or something.

    I don’t know what it is, but I’m just trying to say when it goes to 40-60, thats awesome, but even at 20-30 its waaay more playable. Thank you!

44. Good work LR!
    When can we expect b15? or even full 11.50? Are there many more bugs to kill?

45. b15 seems to have stolen back all my frame rate gains. Was getting early 40’s (with ORBX TE GB…. 120 – 160 with XP native scenery) today 25 – 28 ORBX.

    World objects on MAX and reflection middle for diddle. Don’t really want to start compromising on these after finally getting them up there with early 11.50 and vulkan

    1. File a bug.

Comments are closed.