First of all, no use in mentioning LM Prepar3D to me. Their policies and licensing fees are ridiculous. How many gamers are violating their terms and use it as an entertainment product?
Yes, maybe gamers that use the simulator for entertainment purposes, are in fact violating the license but, flight sim users never considered themselves as "gamers" so, any other usage other than entertainment ( learning aviation, for example ), is covered.
FSX is dead, and we are not developing anything new for it. And in the unlikely case LM would stop making it available to everybody with a Credit Card, we'll develop for other platforms (X-Plane, FSW, etc.), but won't go back to FSX.
For FSX, this is a fact and not something I'm making up. For KSDF, it is particularly slow in appearance, whereas PHNL appear almost immediately. But yeah, it is down to complexity...
That's exactly what I've said. If we made the SAME scenery with a .BGL, you would have had a much longer progress bar, but the scenery would "appear" as soon as the progress bar ended. But the overall loading time would have been the same compared to a similarly detailed scenery. Again, in FSX.
Don't get me started on HDR. The biggest and latest stunt out of Hollywood when 3D failed (again...). HDR has got nothing to do with illumination intensity/strength, as in lumen. For MS games, this is OpenGL/Direct3D light property stuff. See attached screenshot from FSDT PHNL, taken today. That's how PAPI should appear. You can't fly an approach without seeing the PAPI lights clearly.
We know perfectly well how a PAPI should look like, and that's how it looks like on a sim that supports HDR (that is P3D, of course) so, I guess it IS useful...
your screenshot show the really outdated default AFCAD lights we used years ago for PHNL, but using default runway lights is not possible due to how the scenery has been made, which is entirely contoured in 3d, while PHNL is still old technology flat FS8-style scenery.
The common trick I mentioned is particularly useful because active sceneries will load even when flying 40,000 feet above them. I flew from KIAH to KSDF with (K)MEM as VOR/waypoint, and the Airbus X I was flying stalled and fell 10,000 feet due to the loading of the KMEM scenery.
Now you are referring to the pause. I was referring to the supposed memory saving, which is not an issue, as I've said. If it's just the pause you are worrying, we can surely prevent the loading of the scenery at high altitude.
However, your remark still seem strange, because we also have altitude checks on all objects, so they are not loaded at 40K feet and, it's really not possible that loading of KMEM resulted in an airplane stall. We surely don't do anything to the flight model itself. Maybe, it was the autopilot system of that particular plane which was confused by a pause.