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...

 

Do you remember which approach you had selected?

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.

The current ILS 25L chart shows that the 210 radial being referenced is indeed from the LAX VOR. But, it is interesting to note that the text of the procedure in the Navigraph AIRAC does not give any any indication of WHERE the radial originates from. I wonder if that might be the source of the problem? It specifies a radial, without linking the radial to a navaid.

 

The text of the Aerosoft AIRAC by contrast, simply says to fly a heading of 249 degrees to fix CATLY.

 

Perhaps the reference to a radial without specifying a radial FROM a specific navaid causes the internal calculations in the FMS relating to the missed approach segment to get into a loop that never exits. An unterminated loop can definitely produce a memory leak.

 

Perhaps not a case of a bug in the programming of the FMS, but a case of the FMS trying to calculate a procedure in the AIRAC which has incomplete data? I might be completely wrong, but then again, the "radial" reference in more recent Navigraph AIRACS seems to be one item that does NOT appear in older Navigraph data (with no VAS leak), nor in the Aerosoft nav data, which also seems to be leak-free.

The current ILS 25L chart shows that the 210 radial being referenced is indeed from the LAX VOR. But, it is interesting to note that the text of the procedure in the Navigraph AIRAC does not give any any indication of WHERE the radial originates from. I wonder if that might be the source of the problem? It specifies a radial, without linking the radial to a navaid.

The text of the Aerosoft AIRAC by contrast, simply says to fly a heading of 249 degrees to fix CATLY.

Perhaps the reference to a radial without specifying a radial FROM a specific navaid causes the internal calculations in the FMS relating to the missed approach segment to get into a loop that never exits. An unterminated loop can definitely produce a memory leak.

Perhaps not a case of a bug in the programming of the FMS, but a case of the FMS trying to calculate a procedure in the AIRAC which has incomplete data? I might be completely wrong, but then again, the "radial" reference in more recent Navigraph AIRACS seems to be one item that does NOT appear in older Navigraph data (with no VAS leak), nor in the Aerosoft nav data, which also seems to be leak-free.

yes exactly.

 

Thx for confirming that it looks strange to you as well!

 

Well, if the simple miscoding of Navigraph is the cause of this then we shall soon find out.

PMDG said they they are looking at it, so.

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.

 

Thanks. 10 hours into VHHH (Taxi2Gate) to KJFK (FSDT), have not entered arrival runway (only STAR) and sitting at 1.5GB of VAS remaining.

The current ILS 25L chart shows that the 210 radial being referenced is indeed from the LAX VOR. But, it is interesting to note that the text of the procedure in the Navigraph AIRAC does not give any any indication of WHERE the radial originates from. I wonder if that might be the source of the problem? It specifies a radial, without linking the radial to a navaid.

 

The text of the Aerosoft AIRAC by contrast, simply says to fly a heading of 249 degrees to fix CATLY.

 

Perhaps the reference to a radial without specifying a radial FROM a specific navaid causes the internal calculations in the FMS relating to the missed approach segment to get into a loop that never exits. An unterminated loop can definitely produce a memory leak.

 

Perhaps not a case of a bug in the programming of the FMS, but a case of the FMS trying to calculate a procedure in the AIRAC which has incomplete data? I might be completely wrong, but then again, the "radial" reference in more recent Navigraph AIRACS seems to be one item that does NOT appear in older Navigraph data (with no VAS leak), nor in the Aerosoft nav data, which also seems to be leak-free.

A contributor, perhaps, but I'm not certain the sole source. I'm able to shoot approaches just fine into other airports that have similar text for their missed approach procedures. In 1502 (I'm assuming 1503 also but I haven't checked for changes), KDEN.txt doesn't specify a "source" navaid for its missed approach to ILS runway 26. Yet, it looks very similar in profile to KLAX ILS 25L.

 

Interesting Aerosoft says to fly a heading direct, since technically that's incorrect (I'm sure the difference is barely noticeable on radar but if it's published to join a radial...then I'm sure I'm expected to fly a radial; though us pilots should be cross checking that FMS info anyway once it automatically populates).

Last night did  Sydney YSSY to Perth  YPPH. Vas usage reamined stable at 1.86 Gig on FSX steam beta on arrival - no crashes and very smooth - Now three flights over 3 hours under virtual airline conditions and login  and no issues. Frame rate as displayed by steam on the FSx screen in right corner as between 20 -30 FPs are smooth. :rolleyes:

Listen up!

We'd like to have as many of you from this thread as possible test the fix we think we've come up with. The results with the beta team have been somewhat ambiguous, so we'd like to go to the source of the reports on the issue here and see what you guys think. Email me directly at [email protected] with the subject "777 VAS test" and we'll reply back with instructions.

 

Thanks

Listen up!

We'd like to have as many of you from this thread as possible test the fix we think we've come up with. The results with the beta team have been somewhat ambiguous, so we'd like to go to the source of the reports on the issue here and see what you guys think. Email me directly at [email protected] with the subject "777 VAS test" and we'll reply back with instructions.

 

Thanks

Done. Thanks!

 

 

Email me directly at [email protected] with the subject "777 VAS test" and we'll reply back with instructions.

Done today at 12:25am EDT.

Have you guya heard back yet from Ryan? I also emailed hims few hours after his post. I followed the reports here closely anf was able to relplicate the same VAS leak, seemingly introducdded by the latest AIRACs and the missed approached coding.

 

Leo Cal

Have you guya heard back yet from Ryan?

No. Haven't heard from him yet as on Tuesday PM.

glad to know that I am not the only one having oom issue which maybe associated with AIRAC cycle. My case is a little bit different, oom always occurs while approaching VHHH, and I found that vas was continuously leaking while cruising, although I have tried everything I can do like lowering graphic settings, as do you guys. The strangest thing is that Vas is very stable while cruising when I fly from VHHH to other places...but not the opposite....

glad to know that I am not the only one having oom issue which maybe associated with AIRAC cycle. My case is a little bit different, oom always occurs while approaching VHHH, and I found that vas was continuously leaking while cruising, although I have tried everything I can do like lowering graphic settings, as do you guys. The strangest thing is that Vas is very stable while cruising when I fly from VHHH to other places...but not the opposite....

Which specific runway/approach at VHHH did you select in your FMS?

Which specific runway/approach at VHHH did you select in your FMS?

ABBEY3A for 07L

 

I will be grateful if you could help me test the scenario using PMDG 777, AIRAC Cycle 1403 and Taxi2Gate VHHH

 

In my case, OOM ONLY occurs when VHHH is the destination of the flight. That means, if I depart from VHHH, oom will NOT occur, but when I approach VHHH, oom occurs.

 

 

ABBEY3A for 07L

That's interesting. I just finished a 15 hour KLAX-VHHH flight using same STAR but 07R. The VAS usage went from 2.6GB at KLAX to 3.6 about 200 miles from VHHH. I wasn't sure I would make without an OOM, so I save the flight and started it from 200 miles out. VAS started at 1.9GB and went to 2.6 on the runway. No way I would have made it without a save. This is in the 777 update that is ready to be sent to Aerosoft. I can't say it is the plane because I did not do a reinstall of ASN. I was doing this flight to see what would happen without an ASN reinstall. Now I know.