I seriously applaud this great find!
This is an area I have found gave me problems and check it out its close to the MROC airspace. 
MRQP is not in MSFS2020 so you need to take off from a nearby one.
1 Like
My contention is that it’s not the airspace at all, but the work in identifying the airspace implies that whatever is causing the issue is more likely to manifest where there are congested areas: like class B airspace. It’s similar with the LOD thing I’m looking at. I can’t reproduce this at all w/ low LOD. It just means I’m loading a tiny area. A linear increase in radial vision yields a quadratic increase in area, and subsequently a quadratic increase in the likelihood of encountering these buggy spots.
Now, if you turned your LOD down to 10 and swept the entire area highlighted by OP, I suspect you’ll find the causative area eventually, but because of the tiny area it’s going to take you a very long time sweeping west to east, north to south, but you’ll find it. If your LOD is high, the probability of seeing it grows quadratically (power of two).
6 Likes
Thank you, awesome work!
Just let us know what zendesk answers to this. Hope you dont get an stupid botanswered “…scale down “Render Scaling” to 80…” back too.
Please have a look a this. This is my sardinia stutter flight. The massive stutter starts at the first purple knot after the departure in the north of sardinia. I make an stop in Alghero in the nordwest. After the new departure the stutter stops until the second knot in the southwest. Reproducible.
There are no class B boundaries there but that green corridors. Any idea about this?
(source: https://www.vatita.net/img/firs2.gif)
Amazing work!! You should def get marketplace credit for cutting Asobo work on some of this findings!
Another permanently stuttery area, but not related to the Class B issue. Regular old half framerates rather than <1fps.
This is happening all through the sim… KIAD, KMDT and a lot more areas. They simply managed to mess up a great sim… again!
@GuiltyKey06482 This is bloody brilliant investigative work, extremely well done! Thanks for doing Asobo’s job for them.
76T can be fixed, but you have to sacrifice KDFW:
Spectacular investigation! I hope this creates an “ah ha!!!” moment at MS!!!
Eh? This is exactly what happens. I have checked this almost to the pixel in my problem area. I guess you haven’t read all the other posts that describe exactly this.
1 Like
I have. You have not watched the video I posted that does not demonstrate this.
This is not an fix, this is a one-legged crook on a broken crutch that was mended with duct tape.
1 Like
Brilliant work! Very well done! Bravo!
More tests with drone cam at terrain LOD 10. It’s absolutely not airspace. You can reliably reproduce the bug by spawning at 76T even at minimum LOD. If you head directly west from there, you will find a point where the performance picks back up. If you try to venture back towards 76T (due east), you’ll hit a wall. Back out, everything is good again. HOWEVER, give it about a minute. Then try to venture back to 76T. You will find that you can with good performance. This is symptomatic of a caching system that is doing exactly what it is supposed to do but it seems to be to be operating with a piece of bad data that has outlived its temporal locality. Once it “ages off”, you’re good to go again.
Also potentially explains the bug that can be reproduced by changing LOD’s dynamically even outside of the “black hole” with heap corruption. There is a process that is either bad intrinsically or is not properly sanitizing or catching errant or old data sets.
More testing updates:
Cannot reproduce at 76T when starting facing north (Rwy 35). However, if you go to external view then sweep south or even in cockpit view then sweep south, the issue will begin. This doesn’t appear to be location dependent but seems to show that some assets south of the field (wherever or whatever they are) are problematic and temporal (time dependent). Meaning they will “age off” if you’re sufficiently far away for enough time.
It’s not the Bermuda Triangle. It is the BUTLER TRIANGLE!
Thank you for taking time researching this, documenting this, and sharing it here. You had a good idea to use the drone camera for determine boundaries. And it was a good idea to mash the boundaries of the problem area with the airspaces. Since airspaces are 3D, the adjacent Class B airspace ceiling is 11,000ft. Have you tried taking the drone camera above the ceiling? That is, do you know if the triangles have a ceiling?
Incredible detail in your research, fantastic work!
Also…
A hack for sure. I can close the default airport within the xml code, so that APX22200.bgl doesn’t need renaming. The KDFW addon then needs to be uninstalled via the Control Panel. Then the fix BGL can go into the Community folder.
I just need to get a usable code for KDFW to compile. I still don’t know what ails the default KDFW or what also is wrong with the update addon, but they are the cause.
If someone wants a quick test, I had the issue as soon as I spawned onto the FBO next to 18C at KMEM (also Class B) last night. Stayed mostly in the teens until I took off towards KSDF.
Flew from KEB to PANC, and KEB was fine, but as soon as I approached the Kenai Wilderness I got the stuttering all the way up to PANC. Worst experience yet. It must have been a good 70-80nm stretch.