Just completed round 2 of my vanilla P3D test using the F-22. When I left New York, I was pointed a bit too southward from the get-go and ended up in the African region rather then Europe, but that shouldn't really matter. Results for VAS USED were a bit odd. I did not see a drop out in the ocean as Rob predicted, but there was a small one as soon as I cleared land after departure:

1) After loading F-22 at Newark KEWR and doing a 360 scan of interior and exterior: 2.243 Gb

2) After flying over NYC and just above KJFK: 2.302 Gb

3) Very shortly after passing JFK and over water, quickly dropped to 2.215 Gb

4) Remained steady until about 1000 miles out into the ocean, then suddenly jumped to 2.235 Gb

5) Remained steady until about 1000 miles from the north African coast, then a sudden jump to 2.250 Gb

where it remained until I was over the continent... end of test. Changes were all small, but very distinct since without any add-ons, weather or AI, VAS level was pretty stable, generally +/- 1 Mb.

 

 

Eventually, these three will take over the market if LM doesn't do something fairly soon. I don't even bother with long flights with the triple 7 anymore. It's just too iffy as to whether I'll finish them.

 

Lets not derail this to yet another 64bit thread ... I'm a strong supporter of 64bit, have been since 2005/2006 and gave Phil Taylor endless grief (if Tom were still with us he could confirm) because FSX wasn't pushed out as a 64bit product and I had a hunch FSX was going to be end of life from MS prior to it's release in 2006 ... and that's why it was so very important for me to see it move to 64bit back then, but that didn't happen and it's a empty "I told you so" a decade later.

 

I can't say anything more ... but either way Jay, if P3D was 64bit you still wouldn't be flying a triple 7 as it isn't 64bit ... you'd be at the mercy of 3rd party ... but there are signs "some" (not all) 3rd party developers "tone" might have changed just a little in favor of 64bit ... the migration isn't a process LM can do alone, it's a combined effort with 3rd party involvement.

 

Anyway, back on topic ... when testing the unloading of an airport, it's important that you use a complex 3rd party airport at departure, everything else can be disabled.  It would also help if you were able to provide the extra VAS usage the 3rd party airport induces by:

 

1. unchecking it in the scenery library, exit p3D (wait 2-3 min)

2. Start P3D load the default airport (that you also have 3rd party version off disabled)

3. Do the VC 360 and spot 360 view rotations twice, return to VC, note VAS

4. Open scenery library, check 3rd party airport

5. Exit P3D (wait 2-3 min)

6. Load P3D and select your departure airport (this should now be the enabled 3rd party version)

7. Do the VC 360 and sport 360 view rotations twice, return to VC, note VAS

 

At this point you should be able to determine how much extra VAS the 3rd party airport is consuming (roughly) by subtracting VAS number in Step 3 with VAS number in step 7.

 

So now when you fly away from the 3rd party airport within the same world region (see my image link above for regions) into a less or similar populated areas, you have a rough idea of how much VAS should be recovered once your out of range for the 3rd party airport (visually airports really should only be visible around maybe 20nm-30nm, but just to make sure I suggested 500nm, but 200nm away should probably be sufficient).  In my testing, some 3rd party airports never unload and the VAS after I fly more than 200nm away from the departed airport.

 

Cheers, Rob.

Any thread talking about OOM errors and VAS problems is a "64 bit thread." There's no other solution to this problem other than to stop using addons that use large amounts of VAS.

No, this thread is about VAS differences between V3.3 and v3.4 and trying to identify and/or provide information that might be useful to LM. A memory release problem is still a memory release problem regardless of 32bit or 64bit image (note: "image" means file image, not a graphical image).

Cheers, Rob.

EZDok configures the wrong clipmode for the VC view  this affects VAS and graphics quality. so for testing you should remove this line in your cameras .cfg This may be why some see a diff VAS usage?

 

EZdok sets clipmode = minimum  which is not appropriate for a VC view, you should delete this line from your cameras.cfg if you want valid results for your testing. If you look at the P3D/ESP SDK, clipmode = minimum is more appropriate for an external view of the aircraft.

 

 In the VC mode you will get bad cloud/ground intersections, flickering and flashing of distant objects and different VAS usage.

 

Default FSX and P3D VC cameras don't even use a clipmode setting for the VC by default, ezdok does it for a marginal performance boost but quite frankly your graphics go to garbage with this setting .

Thanks Steve, good to know, I don't use EzDok but I know many other users do.

 

So add that to the list of add-ons to disable while testing VAS usage.

 

Cheers, Rob.

EZDok configures the wrong clipmode for the VC view  this affects VAS and graphics quality. so for testing you should remove this line in your cameras .cfg This may be why some see a diff VAS usage?

 

EZdok sets clipmode = minimum  which is not appropriate for a VC view, you should delete this line from your cameras.cfg if you want valid results for your testing. If you look at the P3D/ESP SDK, clipmode = minimum is more appropriate for an external view of the aircraft.

 

 In the VC mode you will get bad cloud/ground intersections, flickering and flashing of distant objects and different VAS usage.

 

Default FSX and P3D VC cameras don't even use a clipmode setting for the VC by default, ezdok does it for a marginal performance boost but quite frankly your graphics go to garbage with this setting .

 

Correct set clipmode = normal in the camera cfg file and EZDOK can be used;-) for VC

i wondered if there is really a VAS discrepance between 3.2 and 3.4 so i decided to uninstall the 3.4 client and install 3.2.

 

Doing the exactly flight as with 3.4 i really cannot see any benefit in 3.2 concerncing VAS. It is nearly exactly the same use....

Will go back to 3.4 because it really is so much smoother then 3.2.

 

I know this test is not representative.

 

Cheers, Carsten

EZDok configures the wrong clipmode for the VC view  this affects VAS and graphics quality. so for testing you should remove this line in your cameras .cfg This may be why some see a diff VAS usage?

 

EZdok sets clipmode = minimum  which is not appropriate for a VC view, you should delete this line from your cameras.cfg if you want valid results for your testing. If you look at the P3D/ESP SDK, clipmode = minimum is more appropriate for an external view of the aircraft.

 

 In the VC mode you will get bad cloud/ground intersections, flickering and flashing of distant objects and different VAS usage.

 

Default FSX and P3D VC cameras don't even use a clipmode setting for the VC by default, ezdok does it for a marginal performance boost but quite frankly your graphics go to garbage with this setting .

This is not something I have read before and I try and read every tip I can! That is very interesting information I have FSX still for now but am changing that clipmode line to normal in the ezdok vc section of my camera cfg thank you.

New one to me will try tonight don't think related to vast tried early on with ezdock disabled but will try with clip mode normal

Hi,

 

I have tried something totaly different : a fly EGCC to KSFO, same route.

First with a CS777 : after landing iwent to the gate and had about 400 Mo of VAS left

Second with a PMDG 777 : OOM just before landing. I had the first "ding" about 25 nm from KSFO, PYE STAR

 

Yves

I agree time for a 64 bit sim

I agree time for a 64 bit sim

 

I am anxious, as I have to buy must of my 32bit addons again, which will be a big impact in $$$.

I am anxious, as I have to buy must of my 32bit addons again, which will be a big impact in $$$.

It is worthy of anxiety,

 

I dont think they'll all hit the shelves at once though - but still.

 

Apart from the well documented VAS benefits, what other changes are we likely to see with a 64 bit platform to play with and design for

I see it just as Erich put it above, the majority of add-ons will not be released in a 64-bit version on day 1.

 

I don't think the main problem will be the cost of the new add-ons but rather how long we'll have to wait for 64-bit versions of our favorite add-ons.

 

Most likely I think the transition to a 64-bit environment will be a rather slow process that will span over a long period of time until we have what we have today but in a 64-bit environment so I'm sure there will be plenty of time to save up some money :wink: