OOMs identical on both platforms 12 minute to  landing in Sydney on modified FMC Star approach.

 

Over last week have noted this route but noticed a coincidence.

 

FSX steam - 737 PMDG NGX latest version exactly 12 minutes from landing according to VA flight tracker.

P3D version 2.2 -  737 PMDG NGX latest version exactly 12 minutes from landing according to VA flight tracker.

 

NZCH to YSSY I will try with 777 PMDG FSX-SE and 777 P3D versions latest version on both sims and let you know how it goes.

 

Computer being MSi apache pro with windows 10 pro latest build. need to revisit the Log from FSUIPC but I think the VAS shows nothing unusual.

 

Computer twilight zone again Sometimes I wish I had a computer programming degree .... :rolleyes: most flight sim stuff trial and error....

I haven't seen any OOMs as a result of selecting specific runways or airports in the 737, only in the 777. So you may be experiencing something different. Which specific approach did you fly?

This is why I think the size of your video card has a big role on how much VAS FSX uses.  If it wasn't then 64bit OS users should be seeing about 1GB more available VAS in the same configuration then I do. Yet they are using anywhere from 3.2 up to the 4GB limit and OOMing. 

 

Tom Cain

I have asked this question to a hardware and FSX specialist I thrust 100% when it comes to these matters.

 

He said that Win7 works different when it comes to drivers.

So GPU memory size does not have any influence on VAS anymore since Win7.

 

I shared that info at an other OOM/VAS thread here about 2 years ago.

 

Ofcourse if you buy 32bit Win7 then you have the problem again that no more than 4GB can be used in total (shared between FSX and operating system).

 

So with Win7 64 bit and for example 8GB RAM installed, you automatically have the full 4GB RAM available for FSX and the other 4GB for the OS, PLUS the size of the GPU memory (mine has 3GB!!) does not eat up your VAS. 

FSX SP2 (non-Acceleration)

First of all I wanted to say that you found a really really interesting (but annoying) bug.

Well done on the troubleshooting!

 

Initially I would have replied exactly the same way others did: "no way that Nav Data can cause a VAS leak, rediculous!"

 

I have said it before: "when it comes to computer problems there is just no logic about it other than the fact that it is all binary logic 1 and 0", lol.

You just cant rule out anything when it comes to FSX trouble shooting and have to try EVERYTHING, even the unlogic.......which in this case paid off.

 

Well done!

 

Now, I hope this gets fixed by PMDG.

And who knows, in the process some other things will be fixed for others who have VAS/OOM problems for other reasons.

 

 

But in the mean time, allow me to ask just one thin; did you install FSX correctly?

 

There are a few guides available (I have used the one by NickN) and if you dont stick by them then you could see unexplainable problems with FSX down the road.

 

I use acceleration, but with FSX SP2 you have to:

Install FSX

run FSX, boot default tryke flight

close FSX

reboot PC

Install SP1

run FSX, boot FSX and boot default tryke flight again.

close FSX

reboot PC

Install SP2

run FSX and start default tryke flight once again.

close FSX

reboot PC

 

Only now is FSX SP2 properly installed!

 

I too think that this particular problem is between the Nav Database and the PMDG777 software, but still.....just asking.....never rule out anything ;-)

After an initial "WHAT THE..." moment, all I could do was to start laughing, considering the utter irony of the situation - which only a devoted simmer could appreciate. I had just literally OOMed a real aircraft!

 

Quite funny yes, I appreciate the story :-)

But, from a purely operational perspective, it would not be common practice in r/w ops to enter the destination approach into the FMS before departure. Though a STAR might be entered early, the selection of the actual runway and approach would typically

be done only after commencing descent, and when in contact with approach control, or perhaps the final center controller. 

 

 

 

Sure it is.  I've worked for a major US airline and currently another operator of Part 25 aircraft.  Our standard practice is to select a "most likely" approach based on weather, forecasts, and NOTAMs.  This helps for descent/fuel/flight planning, and overall vertical navigation continuity for the flight; also helps with STAR selection that are runway-dependent and associated transitions.  Even the tutorial shows selecting an approach during preflight.  If ATC assigns a different approach or runway, well, it happens all the time.

 

I have to agree with that one.

 

We almost always enter the expected STAR and approach during preflight.

Sometimes, if time pressed, we leave the STAR and final approach out until we have more time to enter that stuff during cruise.....but not normally

 

The fuel prediction for destination is then from end of route/airway direct to destination (which is most likely shorter than if you enter the expected STAR and Approach).

Often it is pretty clear what runway will be in use by just looking at the forecast winds in the TAF.

They really are pretty good.

Sometimes, with light and varying winds for example,  it is more difficult to predict the arrival Rwy in use and it then comes down to how well you know the destination ATC structure (or in our case the FSX AI traffic engine, lol) and what they prefer there (noise abatement/night curfew for a certain rwy/where do the VIP live/etc).

Thanks Martin and Bruche, for trying this and sharing your results. Again, if anyone identifies a repeatble approach that leaks VAS outside of those at KLAX and KJFK identified already, please share that too so we can investigate any differences or commonalities.

Probably no difference in results, but has anyone tried these "leaky approaches" in the -300? (I only have the -200, but for completion's sake to test out another variable or two)

And while I'm thinking about it, how about FSX:SE for anyone?

I do not have the -300 either, nor do I have FSX SE (maybe soon though).

 

What I can offer is to do a KJFK /Drzewicki to KLAX flight.

(KLAX = default FSX airport in UTX and GEX environment).

 

I have Aerosoft Nav data pro v1501 installed.......there should not be a difference, but who knows.

 

 

First of all I wanted to say that you found a really really interesting (but annoying) bug.

Well done on the troubleshooting!



Initially I would have replied exactly the same way others did: "no way that Nav Data can cause a VAS leak, rediculous!"

 

But in the mean time, allow me to ask just one thin; did you install FSX correctly?



There are a few guides available (I have used the one by NickN) and if you dont stick by them then you could see unexplainable problems with FSX down the road.

 

Thanks!  Trust me, there were PLENTY of folks who didn't believe me here, on other forums, via private message, etc.

 

Yep, my latest FSX install was "installed correctly" - rebooting, defragging, etc. etc.

FSX-Se on C Drive

P3d on D Drive

 

Dfrag of SSD not possible. And FSX_SE install direct download so all service packs would be included.

Also the P3d can be defragmentised but i bleieve that windows 10 pro does it automatically last itme I checked. did another flight Sydney to NZCh 2 hours 36 minutes no crash I also backed of settings in P3d.  :rolleyes:

Initially I would have replied exactly the same way others did: "no way that Nav Data can cause a VAS leak, rediculous!"

They have no understanding of memory management in Windows Apps!

 

 

 

I have Aerosoft Nav data pro v1501 installed.......there should not be a difference, but who knows.

Of course there's a difference, the two sets of navdata are generated independently, and I worked with Aerosoft a couple of years ago on NavDataPro.

 

Of course there's a difference, the two sets of navdata are generated independently, and I worked with Aerosoft a couple of years ago on NavDataPro.

Didnt mean to upset you, lol.

 

The procedures that Aerosoft (Lido) and Navigraph (Jeppesen) publish both come from the country AIPs right?!

 

So that is the same data.

 

Then ofcourse both companies go their seperate way in how they present the data.

Little differences, but they both must comply with the AIP.

 

After they are done with converting the AIP data in more user friendly layout, it is then printed as well as converted into data files for FMC use (I guess).

And when you download these data files from Navigraph or Aerosoft, they are then converted into something the PMDG777 can work with no?

Other airplanes addons may need a different format.

 

But since the output must be PMDG777 compatible.....in the end the data format is the same again.

 

Aaah, this thinking out loud helped......but the output data will still have the difference is how the approach is presented right.

As in .....with Aerosoft a CANPA (constant angle nonprecision approach) could start at 10nm final and with navigraph at 6nm final......

 

Is that what you mean?

 

But that missed approach that is causing the memory leak here for KLAX ILS25L......that should be exactly the same in both brands no?

 

My FMC says the following for the 25L missed approach:

R25L

249 HDG

(800)

CATLY

Hold at

CATLY

Alright, focusing on the ILS 25L approach at KLAX. Here is the approach entry in KLAX.txt that causes a VAS leak (from 1502) when I select it:

APPROACH ILS25L FIX HUNDA AT OR ABOVE 3600 FIX LIMMA 1900 RNW 25L TRK 251 UNTIL 800 TRK 180 INTERCEPT RADIAL 210 TO FIX CATLY FIX CATLY AT OR ABOVE 2000 HOLD AT FIX CATLY RIGHT TURN INBOUNDCOURSE 210 LEGTIME 1TRANSITION RIIVR FIX RIIVR AT OR BELOW 14000 AT OR ABOVE 12000 FIX LUVYN AT OR ABOVE 10000 FIX KRAIN AT OR ABOVE 10000 FIX TAROC AT OR ABOVE 9000 FIX DYMMO AT OR ABOVE 8000 FIX FUELR AT OR ABOVE 7000 FIX GAATE AT OR ABOVE 5000TRANSITION SEAVU FIX SEAVU AT OR BELOW 14000 AT OR ABOVE 12000 FIX LUVYN AT OR ABOVE 10000 FIX KRAIN AT OR ABOVE 10000 FIX TAROC AT OR ABOVE 9000 FIX DYMMO AT OR ABOVE 8000 FIX FUELR AT OR ABOVE 7000 FIX GAATE AT OR ABOVE 5000TRANSITION SLI FIX SLI FIX GAATE AT OR ABOVE 5000

Which I've changed to,( from 1309's entry)

APPROACH ILS25L FIX HUNDA 1900 FIX LIMMA 1900 RNW 25L TRK 251 UNTIL 800 FIX CATLY AT OR ABOVE 2000 HOLD AT FIX CATLY RIGHT TURN INBOUNDCOURSE 210 LEGTIME 1TRANSITION SLI FIX SLI FIX GAATE AT OR ABOVE 5000TRANSITION SEAVU FIX SEAVU AT OR BELOW 14000 AT OR ABOVE 12000 FIX LUVYN AT OR ABOVE 10000 FIX KRAIN AT OR ABOVE 10000 FIX TAROC AT OR ABOVE 9000 FIX DYMMO AT OR ABOVE 8000 FIX FUELR AT OR ABOVE 7000 FIX GAATE AT OR ABOVE 5000TRANSITION RIIVR FIX RIIVR AT OR BELOW 14000 AT OR ABOVE 12000 FIX LUVYN AT OR ABOVE 10000 FIX KRAIN AT OR ABOVE 10000 FIX TAROC AT OR ABOVE 9000 FIX DYMMO AT OR ABOVE 8000 FIX FUELR AT OR ABOVE 7000 FIX GAATE AT OR ABOVE 5000

===========================================

 

You'll notice, besides the order of the transitions, the only difference is

 

(1309)

APPROACH ILS25L FIX HUNDA 1900 FIX LIMMA 1900 RNW 25L TRK 251 UNTIL 800 FIX CATLY AT OR ABOVE 2000 HOLD AT FIX CATLY RIGHT TURN INBOUNDCOURSE 210 LEGTIME 1

(1502)

APPROACH ILS25L FIX HUNDA AT OR ABOVE 3600 FIX LIMMA 1900 RNW 25L TRK 251 UNTIL 800 TRK 180 INTERCEPT RADIAL 210 TO FIX CATLY FIX CATLY AT OR ABOVE 2000 HOLD AT FIX CATLY RIGHT TURN INBOUNDCOURSE 210 LEGTIME 1

I am 21/2 hours into my KJFK (Drzewicki) to KLAX (standard FSX) flight and see no leak.

If anything, my VAS use is decreasing!

 

I started out with 1.14GB free VAS (I used FSUIPC to display this) and free VAS has increased continuously.

Enroute for 21/2 hours now and have 1.56GB free VAS now!

 

This is what my Aerosoft navdatabase has in the KLAX.txt file:

 

APPROACH ILS25L FIX HUNDA AT OR ABOVE 3600 FIX LIMMA AT 1900 RNW 25L HDG 249 UNTIL 800 FIX CATLY AT 2000 HOLD AT FIX CATLY RIGHT TURN INBOUNDCOURSE 210 LEGTIME 1

 

So it really is different from yours because it does not have the "intercept 210 radial to Catly" but instead mine goes direct to Catly (on whatever track).

I dont know which version is correct as I do not have current ILS plates for KLAX.

 

I know nothing about FMS coding, so maybe it is normal, but waypoints actually do not have radials.

VORs do but NDB and waypoints only have bearing/track TO or FROM them.

But if you do have to intercept a 210 TRACK to towards CATLY then that would of course be ON the 030 "RADIAL" inbound.

 

The "210 radial from CATLY" (radials are allways from!) is southwest of CATLY and it is impossible to get on that AND go inbound to CATLY.

 

Maybe that is the error in the database and where the PMDG777 has a problem......or maybe this matters nothing at all, dont know.

I dont know which version is correct as I do not have current ILS plates for KLAX.

Procedure according to my current Lido chart:

251°

at 800 LT HDG 190°

intercept R210 LAX to CATLY

climb 2000

Ah ok 210 from LAX.

 

That makes sence, but that is not what the navdate txt says.

(still dont know if that matters though).

 

Anyway, just finished my flight to KLAX 25L ILS.

 

My VAS free remaining reached a high of 1.65GB shortly before KLAS.

Then free VAS started to go down.

More rapidly during descend (as expected) and I landed with 1.21GB free VAS remaining.

 

Just for info, I have very low settings for AI traffic (10%) and no cars driving around and I have also reduced my UTX settings (no tiny roads and bridges, etc) to reduce VAS use.

Last night I tried a flight from YSSY to KLAX and after about 3hrs P3D crashed due to the mentioned VAS leak. I wasn't aware of the problem regarding KLAX and entered the STAR (BUFIE3 with ROSIN transition) and ILS 25L into the FMC before I departed SYD.

 

Exact same flight last night (same LAX STAR), same crash about 3 hours in. Odd that I was able to do CYVR - YSSY the day before with no issues (even starting with FSDT's CYVR).

It´s a shame that such a beautiful and complex aircraft cannot be consistently flown on long-haul flights by most users. I started a flight from LEMD to OTHH about one hour ago and the VAS is already at 3.5Gb and climbing very fast. I´m over the Mediterranean, so it seems to me that the leakage comes from the plane...

 

P3D 2.4 + PMDG777 + FS2CREW + LEMD Aerosoft + FTX Global + Opus Weather + IVAO (no AI traffic)

 

 

 

UPDATE: 15 minutes after posting, VAS Reached 3.7GB.

 

Saved Panel State, Restarted FS and VAS went to 2.3GB. 10 minutes later already at 2.4GB and going up...

For those who have not heard,  PMDG is very aware of the T7 OOM issue.  they've acknowledged it and they are working

on a fix now.

  Until a fix is available,  try withholding FMS entry of the arrival runway and approach procedure until within 150nm

of destination.  I had the OOM issues until Paul and Ryan suggested that I try the this procedure.   I fly the T7 nearly

every day and have not had any OOM related FSX failures since.......   You can also uninstall the T7 and then reinstall

only the original release (base) version of the -200 (with no service packs) until PMDG gives us a fix.  This is what I

did ~1 month ago. The un-updated base pack's FMC can be set up in the normal manner > with arrival and destination

Rwys and Approaches entered, and should be trouble free > even on long haul flights    

   I presently have all of the T7 SPs installed except SP1d (not a "Steamer") so I'm using the first method stated above.

Best to all,

Ken B.