since version 3.4 is out, the max time spend to fly is 1H45, and when i land vas show 700mb with OP=1

 

i am actually above the sea to athenes 2H15 flight, and vas is 989mb always with OP=0

 

Be careful with testing and conclusions because when landing the airport is loaded into VAS and when at cruise you will have a VAS difference ;-)

Just test with the same scenarios...

Hi Rob, 

 

Following your testing method I have the following results: -

 

PMDG 737NGX, EGCC (UK2000, stand 26).

 

OP=1 FPS=34 (locked at 36), VS= 3,330.200K

OP=0 FPS=35 (locked at 36), VS= 3,291.596K

 

Would you class this as a good improvement to keep OP=0 bearing in mind I use PMDG aircraft?

 

Regards

Gary

According to my observation, PMDG birds (NGX/T7) consumes more VAS in 3.4 than they did in 3.3 with either OP=1 or OP=0. Approximately ~200/300Mb increase depending on scenario, which is not a case with Aerosoft Buses. Actually VAS starts to bleed like crazy immediately after loading a scenario. I have NGX loaded at FB KIAD, 100$ custom AI, ASN, UTX USA with all options to ON, GEX, REX/SC, PTA1.6 and immediately on load I have 1.4-1.5Gb VAS left. After 45 minutes at the gate while changing views, spotting AI, I have roughly 900Mb left. Therefore, I lost almost 500Mb.

 

Again, it happens with NGX only. Airbus and Dash are OK, no changes in VAS consumption comparing with 3.3 and earlier versions.

According to my observation, PMDG birds (NGX/T7) consumes more VAS in 3.4 than they did in 3.3 with either OP=1 or OP=0. Approximately ~200/300Mb increase depending on scenario, which is not a case with Aerosoft Buses. Actually VAS starts to bleed like crazy immediately after loading a scenario. I have NGX loaded at FB KIAD, 100$ custom AI, ASN, UTX USA with all options to ON, GEX, REX/SC, PTA1.6 and immediately on load I have 1.4-1.5Gb VAS left. After 45 minutes at the gate while changing views, spotting AI, I have roughly 900Mb left. Therefore, I lost almost 500Mb.

 

Again, it happens with NGX only. Airbus and Dash are OK, no changes in VAS consumption comparing with 3.3 and earlier versions.

 

This is an interesting observation and I would suggest you post this also in the threads over at LM found here and here.

 

 

Following your testing method I have the following results: -
 
PMDG 737NGX, EGCC (UK2000, stand 26).
 
OP=1 FPS=34 (locked at 36), VS= 3,330.200K
OP=0 FPS=35 (locked at 36), VS= 3,291.596K

 

At what point are results deemed to be significant in VAS terms.. 

At what point are results deemed to be significant in VAS terms.. 

 

IMO I would say 100 MB and upwards.

 

Seeing a difference of maybe 20-40 MB won't really do much of a difference as long as you manage to stay above the 200 MB VAS left limit. Doesn't really matter if you set the parking brakes at your destination gate with 240 or 260 MB VAS left however having 160 or 260 MB VAS left will probably be the difference between facing an OOM issue or not.

Hopefully LM will find a solution to this, in case it's confirmed, but not at the expense of a loss in performance, I mean FPS.

Cheers, Ed

This entire discussion shows that no matter what they say, in the end it comes down to the simple fact, that with current add-ons on the market and used in combination with each other, the only definite solution is to develop a 64-bit Platform.

As much as P3D has improved with releasing VAS, something FSX never did, it is still vulnerable to the memory overload.

 

Great point, but remember, FSX Steam was the sim that really started aggressively releasing VAS back when P3D was v2.5. v3.0 just really took that work to another level.  

Actually, I can easily overcome ANY OOM by saving and reloading a flight before TOD. However, it's too much hassle and destroy spirit of the hobby. 

Actually, I can easily overcome ANY OOM by saving and reloading a flight before TOD. However, it's too much hassle and destroy spirit of the hobby. 

 

Couldn't agree more. I know some people suggest that method when you're having OOM issues but to me I wouldn't even consider that a solution and when doing all your flying online as in my case that isn't even an option.

 

However I'm sure LM will come up with some kind of hotfix in the near future that will cure this possible VAS issue that surfaced again in 3.4.

Thanks again for all the input.

 

I would consider significant VAS difference when you see more than 100MB.  PMDG is not the only aircraft I have noted excessive VAS usage, there are others.

 

I'm also seeing that some 3rd party airport VAS usage is not being released even when one is well over 1000nm away from the airport with nothing but ocean below.  This has also been reported and like I said earlier LM have a ticket open, but finding sources of memory problems are incredibly time consuming and in most cases require the source files from the 3rd party vendor who may NOT be willing to release those files to LM for a variety of reasons.

 

As another test for VAS release:

1.  In your scenery library, disable all 3rd party airports except the one you plan to test with, set OPTIMIZE_PARTS=1

2.  Set AI traffic to 0, set road traffic to 0, no weather (clear)

3.  Select F22 (at a gate)

4.  Save scenario and exit P3D (wait 2-3 mins)

5.  Start P3D and load the scenario saved in step 4.

6.  Repeat the 360 degree view rotation both in VC and external in spot view  (take note of VAS)

7.  Taxi to runway of choice and takeoff

8.  Fly in a direction (preferably over nothing but ocean) that is NOT populated and monitor VAS

9.  When 500-1000nm away from the airport note VAS

 

NOTE: do NOT SLEW and/or change SimRate (this will skew VAS results)

 

If you still have any the patience left, repeat the above and use a more complex aircraft like PMDG, Milviz 737-200, Q400 and note the VAS. 

 

And for those that are into more self abuse, repeat steps above only this time in Step 1 disable (Uncheck all 3rd party scenery entries in addition to airports, except the airport you will depart from).

 

It's a lot of work, so I fully understand if one doesn't want perform these rather long tests.

 

Cheers, Rob.

 

 

As another test for VAS release:
1.  In your scenery library, disable all 3rd party airports except the one you plan to test with, set OPTIMIZE_PARTS=1
2.  Set AI traffic to 0, set road traffic to 0, no weather (clear)
3.  Select F22 (at a gate)
4.  Save scenario and exit P3D (wait 2-3 mins)
5.  Start P3D and load the scenario saved in step 4.
6.  Repeat the 360 degree view rotation both in VC and external in spot view  (take note of VAS)
7.  Taxi to runway of choice and takeoff
8.  Fly in a direction (preferably over nothing but ocean) that is NOT populated and monitor VAS
9.  When 500-1000nm away from the airport note VAS

 

Imagine asking the GTAV brigade to do something similar.   'You wha'?

I can tell you without a test that VAS in fact has not been released.

 

My yesterday's flight KIAD-KDFW for example.

 

1. Loaded at KIAD with 737NGX@21:15Z, 1,4GB VAS remainder

2. Left Gate B76 @ 22:00Z with 886Mb left (almost 600Mb drainage) 

3. Crossed FEWWW Intc. of SEVEE1 STAR with ~ 900Mb remainder that tells me that VAS had not been released during the flight.

4. I saved a situation, then reloaded a flight and bingo...I had 1.4GB again.

5. Upon landing and parking at KDFW around 01:00Z I had 900Mb leftover which I consider an acceptable number. 500 Mb drainage is normal figure as FSDT KDFW and ~200 AI were loaded into the flight once I entered into KDFW area.

 

However, if I would have continued the flight without saving it first, it would ended with clear and obvious OOM on a verge of 350-400Mb threshold.

Again....never had this in 3.3 and prior

Just thinking out aloud here but if indeed something changed in how P3D releases VAS (or force add-on scenery) to release VAS in version 3.4 certainly LM would be aware of this and then hopefully they will also be able to address the problem rather quickly without having to find too much time finding the culprit.

I don't want to preach to a choir, but I think it's never-ending catch-and-release game until we see truly 64bit platform. They will fix now, but break again on 3.X or whatever :-) Anyway, I can live with "saved" scenario for now as I'm not going to sacrifice on visuals.