Thank you for your comments.
Yes, KMEM had issues on release day, but that's just because we tried doing something nobody ever done before, like a brand new collision system which allowed features never seen, like a working EMAS that actually stops the plane, or the ability to visit the control tower in first person.
Some of them might have some additional impact, but how much they are noticeable, depends a lot on how many other addons are running at the same time, especially those that tax the Simconnect communication channel, which might result in some stuttering so, we couldn't foresee any of these problems, since we surely don't have so many products running at the same time while developing a product.
As you correctly said, your flight from had "No studder/pause coming in or out", which is of course how the current P3D version is, right now, since lots of them were caused by having to adjust the FSX-compatible version of the scenery in realtime to prevent ground flickering, but the native P3D version we released after a while doesn't have the problem.
And, we disabled by default the "GearBumps" feature, which also resulted in some additional processing required so, it's now optional. The next update will have the option to disable even more stuff. Things that other sceneries don't have in the first place, such as the precise collisions on buildings, which should improve things even more.
Also, with VAS being a so limited resource on 32 bit sims (this will end soon), we had to do aggressive memory optimization, because there would be no way a scenery as large and detailed as KMEM would ever fit in memory. And we succeeded, because while some surely reported stuttering in the initial release, basically nobody had OOM problems at KMEM, which is something that is affecting EVERY big and detailed scenery that has been released recently.
It's really simple, memory optimization doesn't go along with smoothness.
The best way to have a "smooth" scenery, is simply NOT doing any optimizations and just load everything once. If you a LUCKY, and the user hasn't loaded too much stuff, the sim might not OOM, otherwise there's just nothing you can do, and the sim will crash, especially when used together with memory-hungry hi-end airplanes.
The more you carefully optimize, by giving all objects their own specific loading range, and create/destroy objects when they are not needed, you PREVENT OOM crashes, but you will surely introduce some additional processing, because the sim *itself* take a bit of time to create/destroy an object, in addition to the OS itself, which (following the sim request), might do some operations to reclaim the memory that has been just freed up.
I hope that everyone will agree that some "stuttering on approach" is surely better than "crashing on approach"...
But of course, with 64 bit basically upon us (I don't think it's a big secret that all major sim platforms are going to be 64 bit in 2017), lots of these issues will be less of a concern, so we'll be able to lift many of our self-imposed restrictions on loading ranges, which means stuttering should be a thing of the past, since we might be able to afford a bit more of leeway to gain smoothness, since the OOM threshold has been moved forward. And, while on 32 bit there's just nothing you can do, except than optimizing the software to restrain itself, on 64 bit you can BUY relatively cheap hardware ( upgrading to 32GB, for example), to get an OOM insurance.
And again, this will finally demonstrate how useful Couatl is.
Since the whole logic of our sceneries is handled entirely by a very small set of Python scripts, it will be enough to update those, and ALL sceneries that use it will change their behavior, without having to change the scenery itself. The scenery script can adapt automatically to the simulator platform used. It's already doing it now, to handle some differences between FSX and P3D, but the next versions will behave differently it it detects a 64 bit host platform, affecting the logic of memory management, and going back to prioritize smoothness over memory savings. This will be valid for every scenery we made, without requiring much effort to go back working at them individually.
