Man, you people are spring loaded on the defensive. An apology on your part would be appropriate.
Wanted to make it clear that Boone is a fellow forum user as you are, he's not part of FSDT, I understood your message in a complimentary way.
About OOM, it should be clear (and I've gather from your last messages this is also clear for you now) they are not "caused" by CYVR, but CYVR is simply a fairly large and detailed scenery that happened to be released in an area were there wasn't much space available because of the availability of several 3rd party add-ons, and because most people also fly with memory-consuming airplanes nowadays.
This created the "perfect storm" that exposed an underlying issue that was going to happen sooner or later, which is the 32 bit code in FSX with its absolute 4GB limit is not adequate anymore to handle that many add-ons at the same time, which means users will have to learn to make choices, learn to configure their FSX settings, or using the configurations option add-ons should try to offer to lower their requirements, which is what we added in the CYVR update.
The move to DX10 is useful, we support it and will ensure full compatibility with it with all our future add-ons (JFK, KDFW, KLAX, GSX and CYVR already are 100% DX10 compatible), although it's not the definitive solution: it will just save you about 300-400MB or RAM which might be just what you need to fix OOMs, but this is just delaying the inevitable for some time. When most users would switch to DX10, developers will start taking it from granted, and will use that memory too, and OOMs will reappear again, probably when the next big thing will be released.
The real solution would be moving to 64 bit code, but that's not something that is going to happen soon, and surely not for FSX, but for P3D, eventually.
We try to do our best optimizing everything, taking this into account. For example, by offering configuration options like those found in the CYVR installer. And, by moving most of our software code OUTSIDE FSX, in the Couatl.exe, so it won't consume any of the previous FSX address space (Couatl.exe can use its own VAS space, separate from FSX), GSX for example, is running all of its logic code entirely outside FSX, so it can become as complex as we want, without affecting FSX memory usage, XPOI is another example of this: all its code runs outside FSX.
This is a technique that could be probably used with airplanes too, especially for systems simulation and any other program logic, if we'd to create an airplane add-on, it would probably be very easy on memory.
Unfortunately, is not so easy with sceneries, were interactivity code (such as docking systems ,moving hangars, etc.) is maybe 5% of the memory used, most of it it's pure graphics, models and textures so, the only real option is to allow users to manage the textures resolution.
