Just as the title says: perhaps it would be the right time (after the release of V3) to reconsider the known and painful VAS issue.

Yes, LM did a great job on optimizing memory, most probably scenery related leaks and late or never-happening scenery releases from  memory, but as we all know and are able to predict: a 64 bit version is not close, we got to live with the new 32 bit version, perhaps for minimum a year or two or more...

 

So, let's be a bit objective and realize that it is not mainly and not just the dense scenery addons, texture-sizes, water and other settings are what try to steal the most available VAS from us, but the addon applications, utilities, etc. which start and work from INSIDE P3D's VAS space.

 

I personally have quite a lot of (536) scenery areas (now ported to v3) but it is very easy to measure and test that while running the sim, the most initial VAS is taken by those applications which run in the P3D VAS space.

Just a few to mention here (there are much more out there which try to fill the dll.xml file):

 

FSUIPC (probably a good exception as it needs to run inside...)

Addon Manager for GSX and their sceneries

AccuFeel

ASN

RAASPRO

MCE

FSTramp

SODE

ObjectFlow

PMDG

Aerosoft's dlls, LHSIM's dll and a lot of other single-scenery dlls

VATSIM and IVAO clients

etc... etc.

 

Of course some of these examples don't need too much VAS, whereas others (like FSTramp) eat up hundreds of MBs of the valuable VAS space.

I just felt to mention this, because parallel to the re-structuring of the config files and folders by LM, perhaps it was time for the 3rd party designers to reconsider and try to port their addons out of the P3D VAS space. Most of these addons would happily work OUTSIDE of the sim, as executables, without any functional differences.

I seriously think that THIS desired change could save the most VAS for us, although the v3 enhancements and fixes seem to be very effective.

 

Lapi

 

FWIW, ASN runs outside the VAS and interfaces to the sim core via SimConnect (remote via a LAN if you so desire).

 

A lot of applications can't run asynchronously from the sim core, so to move them out would require some pretty tricky coding to externalize some kind of a synchronous hook into the core.

 

I wonder how much of our limited VAS is gobbled up by unneeded libraries and modules imported by bloated compilers and linkers...the art of simplicity and compact code is long gone!

 

Cheers

This is a good consideration. I actually have different versions of the dll.xml file each with select addon entries depending on what I intend to fly....and it made a VAS difference.....Yes. This is clearly contributing to the issue and there must be a way to not have to load uneccessary apps.