Possible new VAS issue in v3.4

[Ifikratis]

I don't have any serious VAS issues either. Why I am worried about is that there is the FSL Airbus that does not get released for P3D until LM makes another better version. So the question is if LM is trying to make progress in the VAS issue or we will be waiting for ever here..

[Kosta]

Not to AS16.
I have it, but no ASCA.
Yesterday finished a flight with Aerosoft airport addons and ORBX regions, including UTXv2 installed. Mesh too, of course.
Landed with NGX and a good portion of free VAS (I think it was about 600MB free).

[B777ER]

Not to AS16.
I have it, but no ASCA.
Yesterday finished a flight with Aerosoft airport addons and ORBX regions, including UTXv2 installed. Mesh too, of course.
Landed with NGX and a good portion of free VAS (I think it was about 600MB free).

I'm thinking myself that it's ASCA. Going to uninstall that and try AS16 as a standalone. REX TD/Soft clouds for textures.

[Kosta]

Yes, I am also using full complement of REX textures, nothing else. However be careful with REX... for instance, the cloud sizing algorithm shouldn't be used, as it replaces the original .fx file, which has been changed with the latest version of P3D.
This was purely intuition on my side...

[Beau Hollis]

Hello all,

I'd like to thank you all again for your reports. We take our user feedback seriously. We spent a good deal of time looking into VAS usage. Some specific bugs were fixed a as result as Adam mentioned previously:
- Some 3rd-party gauges leaked memory when the panel window resized. That bug dated all the way back to P3Dv1/FSX. We fixed it thanks to a detailed reproduction sample provided by an add-on developer.
-Another reported issue related to slewing very fast around world in top down. This bug was introduced back in P3Dv2.

We don't know of any more specific memory bugs at this time. Our recommendation is that users tune their settings and add-on usage to keep within the current memory limits.

Any time we update the sim, memory usage patterns may vary, and some re-tuning may be required. New features may require memory to implement. For example, as of 3.4, scenery models can now use visibility scripts to be more dynamic. These scripts shouldn't take up much memory, but we can't be sure how a feature like this might interact with add-on content. If an aircraft model with tons of visibility scripts was placed as a scenery model, it's memory footprint might be higher. We understand that for some use-cases, an older version may work better, so we've posted links to past releases to give users the option to go back.

Finally, I'd like to respond to the feedback about memory usage in general. We understand the frustration with OOMs, which is why we worked hard to provide major memory improvements for v3.0. In the move from v2 to v3, many heavy add-on users saw VAS drop by hundreds of megs or more. Performance and memory optimization will remain a high priority for us as the platform evolves. Big changes are often too risky to attempt for a point release or hot fix, which is why our focus has been on addressing specific reproducible bugs.

Thanks

[CJSCH]

Not sure I am in the right discussion forum here as I am unsure of what is causing my PMDG aircrafts (777 and 737) to crash in P3Dv3.4 with hf2 when using ORBX scenery. In my case I have a sudden change from a VC view to an outside view and the sim resets itself after a while to my start point. I can reproduce this at exactly the same spot using ORBX NZ South Island and ORBX Queenstown airport. I start my flight at NZCH and shortly after TO, while making a turn to the next fix, the sim stops in the manner described with following error in the error log:
[error.0]
error=Unable to create effect '(null)'
[error.1]
error=Unable to create effect '(null)'
[error.2]
error=Unable to create effect '(null)'
I offloaded the scenery and made the complete flight with about 1400 MB of VAS available using only the ORBX base pack and the standard airports.
The 2nd flight from NZAA to NZQN goes smoothly until I get close to the ORBX NZ South Island scenery (I do not have the North Island). Then the FL changes all of a sudden by about 500ft, the available VAS drop and the sim resets itself in the same manner. Same error code but on top I also get the error code:
[error.3]
error=Taxiway path with 0 width for over 500 times (up to error.526) and then the same error as above a 2nd time from error.527 to error.529 (error=Unable to create effect '(null)'
Beats me as to why a TWY width comes into play when I am at FL360...
I use AS16 and to test the issue I switched it off a couple of times - same result and no problem with VAS before the 'crash'.
So in my case I will not fly the beautiful South Island of New Zealand until there is a fix of some sort.
I will go over to the ORBX forums and post my experience there as well.
My conclusion is that P3d3.4 with hf2 is a good product but there are add-on products that can create problems. Adam's recommendation to test your add-on products one by one is the best so far, that is if you want to continue to fly rather than get upset. What disappoints me is that I cannot fly the FSL A320 in P3D as FSL are reluctant to release their product until these apparent issues with VAS and CTD are solved. I am an early user of the product in FSX but had only a cursory short trial while I wait for the product for P3d. FSX does not do it for me....and it is off my computer for good.
Sorry for the lengthy note. Hopefully it will put some people on the right track solving their issues with P3d 3.4 hf2.

Charles

[downscc]

Another example of how much worse 3.4 is than 3.3 with VAS management. I've flown the KORD-RJAA trip many times but never without problems in v3.4. Session underway on my workstation right now just hit the wall when overflying PANC where it was no problem for v3.3.

My baseline at pushback VAS used was 3,431 GB and in first hour it increased to 3,631 GB. I kept expecting a decrease in VAS as I overflew the Canadian plains with only scenery being Orbx landclass but it didn't. Six hours into trip and approaching the fix over Anchorage (ELLAM) VAS used was 3,943 GB and I chickened out. I didn't want an enroute OOM so I saved, quit and reloaded. Reloaded VAS used after giving everything a couple minutes was 3,368 GB. Doing the reload process returned 575 MB of VAS allocation. Something that in my simple way of thinking should be done by P3Ds internal housekeeping and heap management.

I have turned off the Aerosoft photoscenery around Anchorage a long time ago, it's not a factor.

We only have a 4 GB budget, opening P3D to the Create Scenario screen consumes 1.1 GB. A loss of 0.5 GB to sloppy housekeeping is significant.

[dgeddesjr]

Thanks Beau, but the simple fact that folks only started seeing OOMs after installing 3.4, while using the same add-ons and the same settings indicates that there is definitely a change in Prepar3d behavior here. It is also verified by several posters that rolling back solves the problem. I think that should be investigated, but that thank you for at least responding in the thread.

[Raphael_Chacon]

Hello all,
...our focus has been on addressing specific reproducible bugs...

Very specific and very very accurate goal on the edge for 64bit release!

- Specicif Aircraft (PMDG...)
- Specific Scenery(FSDT, Flightbeam...)
- Specific OOM behavior (This chat)...

Thanks!

But yes... we still hope another fix somehow to see your thoughts come true, this is all about: high ultimate end systems, addons and possibilities Vs Very low settings requirement to be used due to software memory issues... (may be?)

Againg, looking forward for something.... :-)

[Humpix]

I found out that "PILOT'S - FS Global 2010 FTX Compatible" have some issues with Prepar3D v3.3 - 3.4 (inkl. Hotfix3). In some aereas the VAS increase immediately about 200-300MB and stays there. This makes long flights impossible without OOM´ing.
Here is a sample spot, I have recorded https://www.youtube.com/watch?v=cgl92RZHPnA
Without Mesh, Prepar3d works like a charm...

[Kosta]

Can you post the flightplan (and where this happens approx)? And did you report it to FSP?

[Humpix]

Jep, I write it to FSP also. I thougt it is a good idea to post it here too. Maybe this helps someone - many simmers use this addon. I also read simmilar post here before.
Here is an image of the flightplan incl. all waypoints - https://cloud.humpeler.at/index.php/s/RZPoTSZz9Dx9JFD

Before testing, I have done a clean install and tested the same flight with each addon, one by one and various combinations, until I find the issue. It is reproducible at some spots in europe an north america.

BR!

[Kosta]

Looking good. I'll let the A320 fly the route.

Btw. I am not using FSP mesh, I myself am using (free and IMO much better) FreeMeshX.

[Humpix]

Thank you for cross - testing :-) Please let us know if the freemesh works better in this case!

[Kosta]

Until EVANO, about 740-790mb free VAS.
Somewhere between EVANO and BORDI apparently, something "ate" 100MB away.
Free VAS at BORDI: 650MB.

Measurements from FSUIPC.