As more leading-edge developers push the envelope for detail, fidelity, and the "gee-whiz" factor, it has become readily apparent that FSX is being rapidly pushed over the edge of the infamous 4GB VAS cliff. I would propose that we, the customers, gently nudge our favorite developers to publish benchmark VAS usage for their latest products as part of the usual "requirements" list for OS, CPU, GPU, etc. If they published an average VAS usage, on a clean, vanilla copy of FSX, it would enable us to properly assess their new products in view of our current packages of add-ons to see what trade-offs we might have to make to see their product perform reasonably well on our individual FSX systems.  For example, if my favorite suite of add-ons is currently pushing 3.2GB of VAS and I see a new "must-have" add-on which consumes an average 700MB of VAS, then I know ahead of time I'm going to have to do some trimming before I plunk down big bucks (euros, pounds, whatever) for the latest and greatest, and won't be blindly disappointed and disgruntled when the dreaded OOM bogey bites me on the butt. Just a thought.

As more leading-edge developers push the envelope for detail, fidelity, and the "gee-whiz" factor, it has become readily apparent that FSX is being rapidly pushed over the edge of the infamous 4GB VAS cliff. I would propose that we, the customers, gently nudge our favorite developers to publish benchmark VAS usage for their latest products as part of the usual "requirements" list for OS, CPU, GPU, etc. If they published an average VAS usage, on a clean, vanilla copy of FSX, it would enable us to properly assess their new products in view of our current packages of add-ons to see what trade-offs we might have to make to see their product perform reasonably well on our individual FSX systems.  For example, if my favorite suite of add-ons is currently pushing 3.2GB of VAS and I see a new "must-have" add-on which consumes an average 700MB of VAS, then I know ahead of time I'm going to have to do some trimming before I plunk down big bucks (euros, pounds, whatever) for the latest and greatest, and won't be blindly disappointed and disgruntled when the dreaded OOM bogey bites me on the butt. Just a thought.

 

Try turning of some of the scenery that you are not flying over, or flying so high over it doesn't matter.

I find the bigest impact on VAS, and I have it displayed continuosly in the aircraft I fly, is scenery. Plain and simple.

 

No OrbX enabled...plenty of VAS. Fly low in the PNW with OrbX and I often have OOM errors. After

installing OrbX Global I had to reluctantly dial back the maxed out scenery settings I have been flying with

for years.

 

    Paul

Google SceneryConfigEditor, it will help simplify the process of toggling off/on scenery areas, and you can save sets of scenery.cfgs.   For instance, I have a Europe only set, North America set, etc.   But the point here is that a full scenery library loaded into FSX, including areas you have no intent of flying over, uses up plenty of precious resources.

 

I only wish I had known about this tip years ago.

Guys,

 

The OP is not asking for advice on how to avoid OOMs - pretty sure he knows how! He is looking for feedback on a suggestion for devs to consider ...

This is reviewer task. Any properly wrote review should include this kind of information. Or we can just start a topic where people will be posting information on vanilla vs addon vas usage so other people can know how much it hurts to use something.

 

There is only one issue I see here - FSX as a quite faulty piece of software behaves differently on different configurations. Vide - last discussion about ftx vector and it's vas impact. Some people don't have memory leak, others do - unless it's not everyone developer is not looking at it as an issue.

 

The truth is - I don't think developers will include this kind of information. If you knew how much vas Thessaloniki use would you buy it considering addons you own? I wouldn't. And some people don't dig enough to find information that some sceneries are causing serious issues.

 

It's a trap we all as customers set up for ourselves - we are paying money for every addon, usually more money than the game itself costs.

 

Now please look on ETS2 community - everything is freeware, map which was created for over a year costs 1 euro if you want to download it from a super fast server and the amount of details exceeds sceneries for most of fsx addons which costs 50 euro or more.

 

Meaning - it's not in dev interest to post information about possible flaws, knowing that most of flight simmers will spend those money if they are not aware and in the end dev can always say: "yes, I know, you paid 60 e for this addon but fsx has it's limits - sorry!". For 1000 euro spent on addons I would expect at least one to fix those limits.

 

It's our own rope on our own neck to me. That's why I came back to ETS2 now and I drive instead of flying

I think developers need to consider how they are using textures and developing for efficient use of them. Probably the most effective developer is FlyTampa who use common textures transcribed to their scenery. This is most apparent at OMDB where you see a massive city with simply awesome performance because textures are used very efficiently.

I'm probably going to make some graphs regarding VAS and FPS loss compared to default C172. Fps will be unlimited with no weather at a Podunk strip etc

Guys,

 

The OP is not asking for advice on how to avoid OOMs - pretty sure he knows how! He is looking for feedback on a suggestion for devs to consider ...

 

And a very reasonable suggestion it is!

 

Bill