Just finished my 4:30 hrs flight KATL - KLAX without any oom, landed 25R, airac 1502, start with vas 2.6 landed 2.9/3.0

Do you recall about how far you were from KLAX when you entered the approach for 25R in the FMC? The last EDDP-KLAX flight using 1502 R2 I did, I entered ILS 25R at a distance of 88 mile from KLAX, Not enough time for VAS leakage to effect my flight. Enter the ILS 25R over the North Sea or the UK and I will never make it to the east coast of the US without an OOM.

Well, the plot thickens with another data point:

 

Decided to test the opposite direction last night, KLAX-KJFK.  The winds were favoring the 22s, so I selected ILS22L approach while at the gate at KLAX.  By coincidence, sure enough, an hour into flight, the same VAS leaking symptoms became apparent, leading to an OOM 3 hours and 55 minutes into my flight.

 

Looking at the approach profile, particularly the missed approach profile in KJFK.txt, it looks very similar to the problematic KLAX approaches.

 

 

APPROACH ILS22L FIX ROSLY AT OR ABOVE 3000 FIX ZALPO 1800 RNW 22L TRK 225 UNTIL 500 TRK 160 INTERCEPT RADIAL 190 TO FIX CHANT FIX CHANT AT OR ABOVE 3000 HOLD AT FIX CHANT RIGHT TURN INBOUNDCOURSE 010 LEGTIME 1

 

Note the track and climb, then turn to intercept a radial to a fix and hold.  However, the head-scratcher here (if this whole scenario wasn't one already), is that I was able to fly successfully to the KDEN ILS26, which has a similar approach as well.  So, unfortunately, it doesn't seem we can say "any approach with a climb straight ahead, climbing turn, to intercept a radial to a fix and hold" are the problem.

 

If anyone would like to try and repeat my results, feel free to attempt a medium-to-long haul flight of a few hours or more with KJFK ILS22L preloaded in the FMS.

Kyle are you using Orbx regional scenery? I had an issue with PNW which I bought when first released. which seemed it should be unrelated, but it was repeatable time after time. Normally I would fly with it disabled, if I wasn't flying in that region. One day I decided to fly from KJFK to KSEA in the PMDG 744, so I activated it. No matter what I did with PNW active I would OOM on taxi out of KJFK Different AFCADs/Scenery like FSDT, default or user freeware, made no difference, Same with flying to other non Orbx areas, with PNW active. The only way I could get a complete flight was to switch back to default (Actually UTUSA). Then I could fly to destination, I may still not make it, but I would last until final approach and landing, Since then, I don't use Orbx regional scenery anymore, (I do use FTX Global though) and never had OOM's that early in the flight again, and never come close to it until approach and landing. I normally flew at that time with 100% traffic, Extremely dense scenery and very dense autogen. It just surprised me that scenery that distant from my current location at origin could have apparently have that much influence on system resources. If you do have Orbx Regional scenery active try switching back to default (FTX or UTUSA is ok) and see if you still OOM that early in flight. (You may still OOM later on approach or landing)

 

Tom Cain 

Kyle are you using Orbx regional scenery? I had an issue with PNW which I bought when first released. which seemed it should be unrelated, but it was repeatable time after time. Normally I would fly with it disabled, if I wasn't flying in that region. One day I decided to fly from KJFK to KSEA in the PMDG 744, so I activated it. No matter what I did with PNW active I would OOM on taxi out of KJFK Different AFCADs/Scenery like FSDT, default or user freeware, made no difference, Same with flying to other non Orbx areas, with PNW active. The only way I could get a complete flight was to switch back to default (Actually UTUSA). Then I could fly to destination, I may still not make it, but I would last until final approach and landing, Since then, I don't use Orbx regional scenery anymore, (I do use FTX Global though) and never had OOM's that early in the flight again, and never come close to it until approach and landing. I normally flew at that time with 100% traffic, Extremely dense scenery and very dense autogen. It just surprised me that scenery that distant from my current location at origin could have apparently have that much influence on system resources. If you do have Orbx Regional scenery active try switching back to default (FTX or UTUSA is ok) and see if you still OOM that early in flight. (You may still OOM later on approach or landing)

 

Tom Cain

 

Negative, it's disabled/removed for testing purposes. I do own FTX Global and Orbx Palm Springs but no other regions that I usully use.

Negative, it's disabled/removed for testing purposes. I do own FTX Global and Orbx Palm Springs but no other regions that I usully use.

The thing I can't wrap my head around, is why you are losing VAS mid flight? When I describe a leak I'm talking on the ground, once I get in the air VAS stabilizes and in fact even gets better. Only when I'm coming in for a landing when the destination ground scenery starts loading in do I start losing VAS again. That's when I'm susceptible to  running out and OOMing. I'm running the KATL KLAX flight again right now this time with FSX Box, and I upped my scenery settings higher than I normally do, and switched back to DX9. My autogen is set to Very Dense, scenery is extremely dense 100% WOAI traffic (A large colection, especially US and European airlines) I even set the Texture_Max_Load to 4096. I do run at only 1280x768x32, due to limitations of my projector. Still I started out with 1.1GB VAS available (FSUIPC reported), at takeoff I dropped down to 595MB available, but I'm currently 2.5 hrs in the flight, and I'm currently at 805MB available. Bare in mind my system is only a 3Ghz C2D running Vista 32 bit OS and a 1GB GTX 460 Video card. So that means currently I'm only using 2.2GB VAS, since unlike a 64bit OS I'm limited to 3GB VAS! This on a configuration PMDG doesn't  even support the T7 to even work. 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. I ran the same flight with the same settings yesterday but in DX10 FSX SE and made it all the way to the gate at KLAX, and didn't start pinging to I got there. What are the settings and resolution you are using for your testing? 

 

Tom Cain

The thing I can't wrap my head around, is why you are losing VAS mid flight? When I describe a leak I'm talking on the ground, once I get in the air VAS stabilizes and in fact even gets better. Only when I'm coming in for a landing when the destination ground scenery starts loading in do I start losing VAS again. That's when I'm susceptible to  running out and OOMing. I'm running the KATL KLAX flight again right now this time with FSX Box, and I upped my scenery settings higher than I normally do, and switched back to DX9. My autogen is set to Very Dense, scenery is extremely dense 100% WOAI traffic (A large colection, especially US and European airlines) I even set the Texture_Max_Load to 4096. I do run at only 1280x768x32, due to limitations of my projector. Still I started out with 1.1GB VAS available (FSUIPC reported), at takeoff I dropped down to 595MB available, but I'm currently 2.5 hrs in the flight, and I'm currently at 805MB available. Bare in mind my system is only a 3Ghz C2D running Vista 32 bit OS and a 1GB GTX 460 Video card. So that means currently I'm only using 2.2GB VAS, since unlike a 64bit OS I'm limited to 3GB VAS! This on a configuration PMDG doesn't  even support the T7 to even work. 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. I ran the same flight with the same settings yesterday but in DX10 FSX SE and made it all the way to the gate at KLAX, and didn't start pinging to I got there. What are the settings and resolution you are using for your testing? 

 

Tom Cain

The VAS leak isn't necessarily just in flight. I can select one of the problematic ILS's in my FMS while still at the gate and let it sit, untouched, for 4-5 hours and OOM.

 

Middle of the road, close to default medium settings (again for testing purposes, my usual settings run what I'd classify as medium-high since tend to lean toward fluidity and performance over eye candy), at 1920x1080 resolution in windowed mode (with either 1024 or 2048 textures; have attempted both for testing). AI completely off. Autogen dense. Cloud draw distance 60 NM (for now). Water 2.x Low. Cloud coverage maximum. Global texture resolution maximum. Scenery complexity maximum. FPS locked at 30. Usually use DX10 now but for testing switching between DX9 and DX10.

The VAS leak isn't necessarily just in flight. I can select one of the problematic ILS's in my FMS while still at the gate and let it sit, untouched, for 4-5 hours and OOM.

 

I just completed the flight, had 756MB available at TOD but started pinging with <250MB on final, but made it to gate. at about 217MB. So that's total of 2.8GB used out of 3GB. So in theory if I was running a 64bit OS I should have 1.2GB free. What I think is happening is FSX DX9 or DX10 is allocating the full size of video memory available, In my case 1GB with people with 2GB cards 2GB. Which is leaving the same 2GB VAS available to FSX itself on their 64 bit systems, that my 32 bit system has with a 1GB card. DX10 removes the necessity for the application to shadow copy video memory in it's own space that is required in DX9, but it doesn't mean it can't. DX10 was new when FSX implemented it, and then only partially, in fact it was suppose to be the launch application of DX10 on Vista at RTM, but it wasn't ready in time,  so I'm willing to bet they never modified how they allocated video memory, since it had to support both DX9, and DX10. This is why DX10 only does marginally better in terms of VAS than DX9 since it is more efficient. I would really love to see the VAS readings of someone running a 64bit OS but only a 1GB video card. with similar settings.

 

A couple of things, you mentioned you run in window mode, I fly in full screen, but I noticed I lose about 100-150MB of VAS if I switch to Window. Going back to full screen, I get it back. Second, do you monitor actual video memory usage in flight. Using GPU-Z I show that I'm using only about 450MB actual video memory out of the 1GB available.

 

Tom Cain

II don't know if this helps, but I just completed a 17 hour flight from KDFW to VHHH with default scenery and ASN.  No VATSIM or any VAFAS of any kind.

 

Landed at Hong Kong with 652MB free.  No dinging of any kinds.

 

Very smooth flight all the way through.

 

John Bradley 
AAL132

Second, do you monitor actual video memory usage in flight. Using GPU-Z I show that I'm using only about 450MB actual video memory out of the 1GB available.

 

Tom Cain

 

Yep, and there's nothing out of the ordinary or significant difference between flights with the 777 that have the VAS leak, and those that don't

At the request of PMDG tech support I am going to do a EDDP-KLAX using 1502 KLAX.txt but not select an approach until about 100 miles left to KLAX. That should workout okay.

I wanted to report on this flight. Using 1502 KLAX.txt. VAS usage was 2.5 at T/C, 2.8 at T/D, and 3.6 at a KLAX cargo ramp. ILS 25L was not entered into the FMC until 88 nm from KLAX. Enter ILS 25L into the FMC over the North Sea or the UK and the flight would OOM before reaching the US.

 

 

Using 1502 KLAX.txt.

This EDDP-KLAX flight used 1407 R2 KLAX.txt. VAS except at KLAX was essentially the same. VAS at cargo ramp at KLAX was 3.2 compared to 3.6 using 1502. Why? 88 nm of 1502 leakage increased VAS by .4GB.

Looks like 1503 is hot off the press, anyone have a chance to try it yet?

Looks like 1503 is hot off the press, anyone have a chance to try it yet?

I plan on replacing the 1503 KLAX.txt with the 1407 R2 KLAX.txt. No way am I going to OOM a 12 hour flight to find out it's still screwed up. You try it first. Let me know how it turns out.

Hi guys!

I'd like to buy the 777 but I want to know, honestly, if the problem of VAS exists and makes impossible to do a flight of a few hours. The idea of having to minimize the various settings of the simulator - now regulated to a medium quality - to use this aircraft really do not like. Now with the Aerosoft Airbus and ASN (no REX) my VAS stays around 2GB. Because the 777 is not refundable I'm a little apprehensive about spending $90 and then find myself with a product unusable with my system  :(

 

Thanks for your help!

Regards, Massimo Solimbergo (future NGX for P3D pilot and probably 777  )

Hi guys!

I'd like to buy the 777 but I want to know, honestly, if the problem of VAS exists and makes impossible to do a flight of a few hours.

 

For me, it does to specific airports if I select certain approaches (albeit, we aren't quite sure why yet).  So either I have to avoid these airports/runways or not program an approach in the FMC, otherwise I'll have a VAS leak and OOM within about 3-5 hours.  The 777 used to work just fine for me until, it appears, the more recent AIRAC cycles, which we are trying to investigate in this thread.

 

I, too, was hoping to buy the -300ER expansion soon, but I'm holding off until we can find a definitive fix.