A 19 hour test in the NGX?

 

Yes, I stopped FSX after 19 hours.

And B77L for comparison in that scenario.  Will likely try KSEA or one of the other airports also side-by-side in the coming days.

 

Can anyone confirm the ILS 16L leak is fixed? I am currently doing KJFK to KSEA with the 777 and T2G KSEA. I loaded up the approach (grant, I loaded it about 2 hours out when I was prepping for my descent) and I saw the VAS usage increase about 200MB in matters of 5 minutes (VAS was pretty solid since departure @ JFK around 3.0). I load up ILS 16R, ILS 16C, and RNAV 16L and none of them seems to have problems with VAS. It stays pretty rock solid @ 3.217G to 3.218G

 

Addons running:

AS 2016 + ASCA (sky texture and cloud structure only) + REX Essential Plus (texture @ 1024)

FSCaptain

Multi Crew Experience

FSRealTime

vPilot

ORBX Global & OpenLC NA

Can anyone confirm the ILS 16L leak is fixed?

None of the leaks have been fixed because PMDG is busy with the 747 and have yet to push out a patch. That said, I will agree with the other posts, the best way to avoid this is wait until you get close to Top of Descent before entering STAR and approach. Contrary to the title of this thread, the bug is also present in the FSX versions.

No, ILS 16L at KSEA still causes a leak for several Customers in this thread.. The patch PMDG previously released fixed some airports for some (ILS 25L at KLAX for instance).

I did PANC-VHHH ILS07R Cargo Ramp C21 with no OOM. Missed Approches for ILS07L, ILS07R, ILS25L and ILS25R were deleted from from PMDG>sidstars>VHHH. I accidently deleted all transitions for the above runways also. The complete route including the approach to ILS07R was entered while on the ground at PANC. VAS usage at 4 points during the trip were 2.1GB at 1:07, 2.4GB at 6:52, 2.4 at 9:28 and 2.8GB at C21 VHHH at 10:30.

 

 

I accidently deleted all transitions for the above runways also.

 

Haha that is easy to do.

I am going to give up flying for this year or more. I thought I had everything fixed, sliders a notch lower and no fps problems. But an OOM on approach to LAX yesterday and this morning right now an OOM in the middle of northern Quebec flying east to Europe from LAX. I had no approach programmed into my fmc, the route only. and an OOM 5 hours into my flight ruining it. Upgraded to steam edition but the Ops Center isn't working, panel ini files not installing and the data uplink is broken. Tired of this. I'd like software that works is that too much to ask. Going to take a break and pray the 747 does not have a memory leak and the P3D price is reasonable... - David Lee

Basically Excel and a few custom VBA macros I wrote.

Hi Kyle

 

Any chance that spread sheet or macros could be made available so I can also do some testing?

 

Regards

 

Jim Mclean

Kyle, don't worry about the macros I muddled through to do some graphs of my own.

 

I ran a test similar to what you described and I didn't see any increase in VAS usage which surprised me as you guys seemed pretty consistent in repeating the issue.

 

My test consisted of P3D v3.4, sat on apron of default Eglin (KVPS), only the APU running to provide power and an active flight plan direct to KSEA 16L via a STAR.  No Traffic and only a default P3D weather theme running. I didn't record any data on the first run but noticed no increase in VAS usage.  Then remembering one statement in the middle of this long thread that questioning whether anyone had tried different Navdata I realised that you guys were using Navigraph and I use Aerosoft.

 

I loaded Navigraph and repeated the test and noticed a constant drain on VAS.  I stopped the test before 4 hrs as the results were only going one way, down.

 

I then reloaded Aerosoft Navdata, restarted the PC and set up the identical situation and ran the test again.  For both those tests I logged VAS data in FSUIPC.log and extracted that data to excel to make some graphs.  I think they speak for themselves.

 

 

 

 

Now I don't know if this is a definitive answer to everyone's problems but from my point of view it seems all you problems are not with PMDG 777 or FSX/P3D but actually Navigraph data.  I'll be sticking with Aerosoft for now.

 

All the best

 

Jim

Kyle, don't worry about the macros I muddled through to do some graphs of my own.

 

I ran a test similar to what you described and I didn't see any increase in VAS usage which surprised me as you guys seemed pretty consistent in repeating the issue.

 

My test consisted of P3D v3.4, sat on apron of default Eglin (KVPS), only the APU running to provide power and an active flight plan direct to KSEA 16L via a STAR.  No Traffic and only a default P3D weather theme running. I didn't record any data on the first run but noticed no increase in VAS usage.  Then remembering one statement in the middle of this long thread that questioning whether anyone had tried different Navdata I realised that you guys were using Navigraph and I use Aerosoft.

 

I loaded Navigraph and repeated the test and noticed a constant drain on VAS.  I stopped the test before 4 hrs as the results were only going one way, down.

 

I then reloaded Aerosoft Navdata, restarted the PC and set up the identical situation and ran the test again.  For both those tests I logged VAS data in FSUIPC.log and extracted that data to excel to make some graphs.  I think they speak for themselves.

 

 

 

 

Now I don't know if this is a definitive answer to everyone's problems but from my point of view it seems all you problems are not with PMDG 777 or FSX/P3D but actually Navigraph data.  I'll be sticking with Aerosoft for now.

 

All the best

 

Jim

 

Thorough investigation good work. Is there a difference from Navigraph or Aerosoft? I only use Navigraph but if moving to Aerosoft fixes my memory leak I'll buy As next time. - David Lee

Hi all

 

I went one step further tonight.  I compared ILS16L approach from both the Navigraph and Aerosoft data sets and noticed a difference:

 

Navigragh:

APPROACH ILS16L FIX KARFO AT OR ABOVE 3200 FIX DGLAS 1900 RNW 16L HDG 165 UNTIL 900 TRK 131 INTERCEPT RADIAL 161 TO FIX TEBNE FIX TEBNE AT OR BELOW 2000 FIX MILLT AT OR ABOVE 5000 HOLD AT FIX MILLT RIGHT TURN INBOUNDCOURSE 341 LEGTIME 1

 

Aerosoft:

APPROACH ILS16L FIX KARFO AT OR ABOVE 3200 FIX DGLAS AT 1900 RNW 16L HDG 165 UNTIL 900 FIX TEBNE AT OR BELOW 2000 FIX MILLT AT 5000 HOLD AT FIX MILLT RIGHT TURN INBOUNDCOURSE 341 ALT 5000 LEGTIME 1

 

The bit in bold was different and it has previously been thought that it was the TRK-Intercept-Radial entry that was causing the issue with VAS so I thought I found the reason why Aerosoft didn't cause the VAS issue and Navigraph did.

 

So, I copied the whole Navigraph approch to ILS16L and pasted it into the Aerosoft Nav Data and ran the test again.  Still no issue with the VAS being depleted so that now rules out the TRK-Intercept-Radial syntax as the cause of the VAS issues.  However, it still shows that there is something with the Navigraph Nav Data that is causing the issue and Aerosoft seems to be clear of the problem.  I still don't know what is causing the issue but it is definable a Navigraph problem from my point of view.

 

Not so much as answers just new problems, sorry.

 

Jim

Jim, very good analysis. i wonder if you would try another approach that give people headaches. From parsing through this thread, it would seem VHHH is one that causes this VAS leak. As well, the transitions from OCK VOR to the runways at EGLL, ie., any of the "OCK" arrivals, then selecting one of the transitions from the of the arrival to the first fix on the ILS for one of the runways at Heathrow has also caused this VAS leakage. The VHHH arrivals I believe are for both the 7's and 25's. If your testing reveals the same as above then I believe you have figured out a way around this VAS issue for now. I for one use the Aerosoft navdata and have never had an OOM. I do use the Navigraph data but only subscribe to the EFB data to pull up on my tablet (very realistic by the way).

Jim, very good analysis. i wonder if you would try another approach that give people headaches. From parsing through this thread, it would seem VHHH is one that causes this VAS leak. As well, the transitions from OCK VOR to the runways at EGLL, ie., any of the "OCK" arrivals, then selecting one of the transitions from the of the arrival to the first fix on the ILS for one of the runways at Heathrow has also caused this VAS leakage. The VHHH arrivals I believe are for both the 7's and 25's. If your testing reveals the same as above then I believe you have figured out a way around this VAS issue for now. I for one use the Aerosoft navdata and have never had an OOM. I do use the Navigraph data but only subscribe to the EFB data to pull up on my tablet (very realistic by the way).

Is there a difference I'd notice using the Aerosoft Navdata? I have used Navigraph only so far. - David Lee

Thorough investigation good work. Is there a difference from Navigraph or Aerosoft? I only use Navigraph but if moving to Aerosoft fixes my memory leak I'll buy As next time. - David Lee

It might fix a memory leak that pertains to the missed approach procedure if you are going to use that runway for landing after a 6-7 hour flight in normal time. If you use time compression the flight will not last long enough. This only applies to certain runways. So if you don't fly to that airport and runway it will not fix your OOMs'.