I have the latest update and still having OOM when landing.

 

Just did a flight from PANC to KLAX

 

P3D 2.5 (latest update)

ASN 5589

PMDG 777-300ER

EZDOK

ORBX Global, Vector, NA / Alaska etc

vPilot

You're going to have to provide more data to successfully assert that there is a VAS leakage in the PMDG 777.  For example, how have you eliminated all other users of VAS and measured a time-based consumption of VAS by the 777?

 

It's been said many times:  An OOM error is not an indication of VAS leakage, it is just an indication that you have asked too much of your allotted memory.

 

 

I have the latest update and still having OOM when landing.

 

As Dan mentioned, OOM errors are not an indicator of a leak, as much as they're an indicator of VAS over-use in total.

 

If it's happening upon landing, it sounds like scenery is more of the culprit, particularly because you list FTX Global, Vector and NA/Alaska (which is a heavy hitter alone, even without the rest).

 

VAS is a sum game. PANC takes memory, NA/Alaska takes (a ton of) memory, Vector takes memory, FTX Global takes memory, and the 777 takes memory, too. If the sum of that goes over the VAS limit, then you get an OOM. While the 777 is a contributor to that (usually about 800MB of it), people aren't entirely correct when they say the 777 is causing it.

 

Please see here:

http://forum.avsim.net/topic/468259-07may15-detailed-discussion-of-resolved-777-vas-leak/

I found aerosoft panc high in vas usage myself.

Have a read thought the link in my sig.

What specific routing did you use in the FMC, which specific approach did you select?  What level of autogen, weather, AI, etc.?  Are you able to repeat this even with clear weather, no other traffic, no sceneries activated?

I have the latest update and still having OOM when landing.

A 4-5 hour flight is not even long enough in real time to even manifest a VAS leakage. You are just grabbing at straws. Try the suggestion of Kyle Weber in post #6. If you run out of VAS then, you could consider leakage otherwise forget it.

I have the latest update and still having OOM when landing.

 

Just did a flight from PANC to KLAX

 

P3D 2.5 (latest update)

ASN 5589

PMDG 777-300ER

EZDOK

ORBX Global, Vector, NA / Alaska etc

vPilot

 

The leak is from Vector. I stopped using it until the next patch is released. Just stick with Global for now. 

The leak is from Vector

Is it a leak or usage. Read post #1 of this thread - http://forum.avsim.net/topic/468259-07may15-detailed-discussion-of-resolved-777-vas-leak/ in particular the section "Anatomy of a Leak". What is this patch you speak of. I have seen nothing from PMDG about this. Possibly it was in reply to a ticket submitted to PMDG technical support?

I think turning off a part of addons you don't need when you are flying will solve the problem for you.

Ah this resurfaced.  Out of curiosity I fired up my B77W at a PANC gate and flew to KLAX.  I am using Aerosoft PANC, FSDT KLAX and Orbx enroute including SAK, PFJ, PNW and NCAL regions for NA; as well as Vector...which by the way I've never had a problem with Vector.

 

Anyway, I notice my VAS remaining was down to about 600 Mb at TOC.  This is not due to a memory leak that by definition takes time to become a problem.  This is due to the combination of tasks I've asked my 4 Gb of VAS to accomplish including scenery, ASN weather and PMDG aircraft.  The fix is simple:  Save the flight after TOC and restart the simulation and load the flight.  VAS remaining increased to 1.7 GB and the flight continued unaffected to KLAX including landing.  I could have improved the KLAX arrival by doing the save/load before TOD as I normally do but it was not required.  Having to do the save/load sequence at TOC is rare but required in this scenario.  I usually do a save/load sequence at TOD if my VAS is below 1 Gb.  This has prevented OOM errors completely.

 

EDIT:  I forgot to mention that I turned off Aerosoft PANC airport and terrain using Scenery Editor in between my save and load after TOC. Didn't want to drag that photoscenery all the way to LAX.

 

 

The leak is from Vector. I stopped using it until the next patch is released. Just stick with Global for now. 

 

Thank  you for pointing this out.

 

Guys, he's absolutely right, there is something in Vector that can potentially make VAS usage run away. I was getting OOMs flying the 777/Aerosoft A320 out of stock airports unless I disabled all options in Vector Configurator except for "Highways" (no suboptions, just the primary tick box).

 

 

 

 

David Ayoub

I guess results vary.  I and many others have no problem with the Vector product.  In fact, most of what vector does has nothing to do with texture loading, it's vector data.

 

I recommend that if you have problems you visit the Orbx forum (when it comes back) and try to find the solution; or, you can just turn it off I guess. That works too.

If you haven't done so, suggest uninstalling and reinstalling the PMDG 777 with the latest version.  I also had the same OOM experience.  I had only ran the latest installer over an existing copy.  Like with my PMDG 737, uninstalling and reinstalling seem to be the only way for me.  

To add to what Kyle and Dan said earlier - you would need to demonstrate that there is a leak over time (significant positive slope on a graph of VAS usage, significant negative slope on a graph of free VAS) while on a long distance (preferably over water) route at cruise for us to consider claims of a new or still existing leak. Several users have written tickets with such claims and I haven't been able to reproduce any of them under a controlled environment. Several users had the older version of the 777 somehow still and were seeing the exact issue we fixed in the last update.

Here's an example of my test of one of those routes a customer wrote in about. I made this by logging the free VAS using FSUIPC and turning the data into a graph in Excel. Notice that during the cruise phase there are fluctuations but on the whole there is very little drop in free VAS. The line is essentially flat during cruise. This flight was over land for the most part so there is some variance to be expected as new areas load in. The massive drop at the end is the Norcal/Bay Area loading in - FlightBeam KSFO, Orbx Northern CA etc all take up a ton of VAS in that area. We keep telling people how huge some of these sceneries are for VAS and graphs like this drive it home. I've seen a drop of over 1GB as FSDT KLAX loads in too for instance.

I landed with around 700MB free (FSUIPC was set to 15 minute log intervals here, so I didn't get the very end - there's a final high detail airport grounds loading that happens on short final that usually drops it significantly more from where this ended.

 

It's also extremely important if you're testing stuff like loading an approach vs. not loading one to keep everything else 100% the same between flight tests. Don't fly with weather, don't use AI traffic or fly online - only load things that you can keep the same. Fly at the same time of day, stay in the cockpit without loading the external views, use the same weights, FMC performance numbers, etc. This is basic scientific method stuff here - you want to isolate the variable you're testing so that nothing else can confound the results.