MrFuzzy

Confirmed, it's not fixed. Also the continuous lightning bolts are still there in all their glory. Smooth and fast for me too, but who bought MSFS on the store cannot switch to Steam unfortunately. If I think that initially I was torn because I was afraid that Steam could cause update issues with a Microsoft game, and chose Steam just because of the timer and achievements...

0x80000000000000 code again. Have you tried the solutions listed at the link I posted?

With SU6 the approach flyback bug should be fixed. If that's true, this fix alone will make it an epic update. In fact I believe it's not acceptable to see the release of a bunch of 30 USD payware aircraft when the basic systems of the default ones, which we paid already more than one year ago, are not functional. They also acknowledged the blocky reflections in absence of wind and are willing to work on the white dot. I am positive about the development. As for the fact they are taking care of the wish list more, we need to understand that the commercial side will always be paramount: sales are generated by new content and graphics improvements, things that the average Joe can understand. How many people do you think fly IFR, use ATC and insert flight plans and approaches in the MCDU? Bug fixing is a grinding work that flies under the radars of most people.

There will always be an option to disable ray tracing. Honestly for the moment it would be enough to make the water not so flat when wind speed is below 5 knots. A minimal ripple would be sufficient to avoid that horrible effect.

Take a look here: https://appuals.com/how-to-fix-event-viewer-error-0x80000000000000/ SSD drives should never be defragged, if you have Windows 10 it should recognize them and trim them periodically (in a few seconds): https://www.crucial.com/articles/about-ssd/what-is-trim

DX12 will certainly fix it if DXR (ray tracing) is implemented. A DX12 wrapper will not fix it, as it didn't fix it on the XBox version. I understand the challenge of not being able to use conventional raster based reflections (the reflections would appear and disappear as you pan the view) but those Minecraft blocks are no longer acceptable after one year. I agree completely on the "patching before stuffing" concept but marketing sees it differently.

After Zendesk tickets and several threads in the past year, MS/Asobo acknowledged the bug and hopefully they will work on it sooner or later. Now vote, please! 🙂 https://forums.flightsimulator.com/t/bug-logged-blocky-cloud-reflections-in-absence-of-wind/328150

Yes, lightning are not fixed yet. I don't see many rainbows though, maybe those are sorted out.

Everything works on stable & dev versions. I have to try the experimental one.

Thanks, I'll give it a try.

No, it's a MSFS issue. https://forums.flightsimulator.com/t/approach-flyback-bug-not-fixed-as-stated-in-su5/253494

The technical ones undoubtedly. I voted 5.

Yes, hopefully they fix it again soon 🙂 Thank you all for the feedback!

I have always enjoyed the sim, even in its most pathetic conditions (10 fps airliners with fixed glass cockpit refresh rate, USA update terrain spikes, SU5 stuttered pop-ins... and other stuff I removed from my memory) I love it and I will always love it, but I believe that the function of the Community is to focus and draw the attention of the developers on what needs to be fixed and improved (without griefing of course) rather than sharing screenshots and jokes. In this regards, I find AVSIM an excellent community.

It can make a difference theoretically, because with higher LOD you download more textures and stuff at both sides of the "corridor" represented by the route. But I don't think it will double with LOD, I can check and report (this must be checked with an emptied and disabled rolling cache of course). However considering how massive are the updates alone, MSFS isn't really viable for capped data users...

Yes, they are totally independent.

Another feature still bugged from release, without any visibility on when/if it will be fixed... MS/Steam should at least disable it or put a warning.

Terrain LOD is supposed (if we look at the name at least) to affect how blurry are distant textures too. However if you consider that it also affects the vegetation and buildings which cover these textures, it's not always easy to judge. See these screenshots taken at TLOD 200 and 400 respectively. Are those textures less blurry at LOD 400 or just covered by trees? As for mountains, I can see a very significant difference even in close mountains and from static screenshots, even more so if you consider that when you fly you also have to deal with the dreaded phenomenon of morphing, which, at LOD 400, occurs farther away from the point of view.

I don't use NVCP or other external tools to limit the framerate, I use MSFS internal setting. 1. In NVCP Vertical Sync: Use the 3D application setting 2. In MSFS Vertical Sync ON and framerate limit to 20 (which corresponds to 1/3 of the refresh rate. 1/3 x 144 = 48) A few days ago I managed to set my monitor at 30 Hz and tried 30 Hz / 30 fps. It's not bad but I prefer 48 fps / 144 Hz because below 60 Hz my monitor has reverse ghosting.

Yes, as others mentioned 1.0 in the settings file corresponds to 100 in the UI, 2.0 to 200. Therefore when we write 4.0 in the settings file, that would be 400 in the UI. If you want to experiment, always remember that the preset line in the config file must be "Custom". If it's High, Ultra or another preset, the sim will ignore the custom LOD setting and restore the default. Thank you all for the feedback!

Do you have a 60 Hz monitor? Otherwise "60" in MSFS graphics menu means max refresh rate of your monitor. I can confirm that VSync works unless it's forced off in nVidia/AMD control panel. I am using VSync on and framerate locked at 48 fps (20 in the menu).

For those who don't wat to read this long post - TLDR / Conclusions: I found that Terrain LOD / Objects LOD 200/200 setting is the best for most configurations and 400/400 an acceptable compromise for high-end machines & demanding users. Even with high-end machines though, 400/400 may cause framerate to drop below 30 in the presence of PG cities, heavy traffic and complex live weather. I believe this is the reason why Asobo limited these settings at 200 in the UI. Long version Today I did some tests to determine what the LOD settings (Terrain and Objects) do separately and found interesting results. I chose the following testing conditions, reproducible for everyone. MSFS version: 1.19.8.0 (current as of today 12 September 2021) Community folder: empty except for the aircraft Aircraft: FBW A32NX 0.6.3 stable version Location: KJFK 31L - engines on as per default setting (flight starting with aircraft on the runway) Time: 10 am local time (14:00 UTC) Weather preset: clear skies Air traffic off Multiplayer off Base graphics preset: 1440p/Ultra, obviously changed to Custom when editing LOD settings in UserCfg.opt file VSync off All the other graphics settings in the config file left as per Ultra preset Screenshots taken after framerate is stabilized: 1) default cockpit view; 2) drone view obtained from default drone position (INS key) and 3) drone altitude set from 2) by pressing R until the lower border of the parking area is aligned with the bottom of the screen I will post the original screenshots as shortcut links to avoid making a huge post. Anyway the screenshots should be examined at full resolution to better appreciate the differences. As for the cockpit and initial drone screenshots, both taken at ground level, obviously they all look the same so I will report only the framerates obtained. Here below my considerations, your comments are welcome. Terrain LOD This is the setting having the largest impact on performance (framerate), RAM and VRAM occupation. It is also the setting that determines the draw distance. VRAM occupation with Terrain LOD 900 reached 13 GB and 16 GB on the ground, respectively with Objects LOD 200 and 900. As the altitude increases, VRAM occupation drops drastically. Keeping Objects LOD at the default 200 setting, there is a clear difference in the draw distance of vegetation and other stuff (not PG buildings) between Terrain LOD 200, 400 and 900 respectively (here below at 130% zoom). However the difference is not as abysmal as the performance loss and I understand why Asobo set the max at 200 in the UI. For high end PCs a compromise can be found at Terrain LOD 400 but beyond that the framerate drops consistently below 30 and makes the max setting of 900 absolutely prohibitive for any CPU currently on the market (and for any GPU but the RTX 3090, due to VRAM occupation higher than 16 GB). Objects LOD This setting is not that heavy on the framerate and has nothing to do with the draw distance. It rather affects the graphics detail of still relatively near objects. Screenshots of Objects LOD at 200, 400 and 900 keeping Terrain LOD at the optimal setting of 400. Differences can be spotted in the airport buildings and nowhere else: at 200 some parked cars and the terminal and jetways windows, that are present at 400 and 900, disappear. Here at 210% zoom, use your CTRL + mouse wheel to zoom further if necessary:

The issue is more apparent at high latitudes. Just try Finland or Sweden and you will see it, even with LOD 400.

I also notice more struggle with certain volumetric clouds at high altitude, but even with 100% GPU and 40-45 fps, the temperature of my 3090 never passes 78-79 °C. 97 °C means that the GPU is not cooled enough, add some fans to extract hot air from the case.

Graphics... they may introduce ambient occlusion, improve water, global illumination, weather, landclass, vector data, mesh, autogen... But, unless a cooperation with Google is in the plans, without streaming of real world textures the world will always look fake and made with repetitive tiles and textures everywhere. I am afraid MSFS won't have competitors in the graphics compartment for long time.