Possible new VAS issue in v3.4

[downscc]

Second session with PMDG 77W from KLAX to EGLL, with FTX ENG and UK2000 EGLL, was normal until about 4 hr when VAS alarm gong sounded. Aircraft was over Lake Erie. Reloaded in progress flight and on arrival into EGLL VAS is low again and was unable to complete session without reloading the flight a second time.

I've spent a few hours this morning loading the PMDG 77W at EGLL Gate 327 and trying different things to lower VAS value at the gate. Weather is off. Deleting Shaders folder decreased VAS load by about 200 MB but nothing else had measurable impact. VAS remaining is about 1,200 MB with little change using default prepar3D.cfg. This is a good number, but sitting at the gate is not flying, which is when the OOM errors occur.

Looking for suggestions, maybe something I haven't tried yet??

[cannow]

I agree there are still major vas issues particularly around EGLL with 3.4 . Until LM give a reply you may want to disable FTX England and Vector if you have it . I just managed to leave the uk the other day with both them disabled . Otherwise I would OOM at the LAM VOR north of London. This was with a take off from EGLL to Moscow . This was with IFly 747 and aerosoft egll and very modest graphics settings autogen sparse . I do have have Europe LC but not as good as ftx England which I have relegated to GA flying. VAS hit 3.8gb at Lam VOR . I do plead with LM to look at VAS again especially for us heavy metal flyers. I am on 2024 textures.

[vmounier]

It feels like we have taken a double step back from the recent improvement where VAS was finally being better restored as unused scenery was flushed out. That being said, I cannot even duplicate an OOM by repeating the same steps, so there appears to be random factors, and I wonder if the culprit could be a dynamic element such as AI or road traffic. I'm not looking at weather (but maybe I should) as this started happening while AS16 was off; unless native weather is involved.

Flew the 747 from CYVR to well past KSEA last night, not enough time to complete the flight but road traffic was at 0 and air traffic trimmed to 50 aircraft, and VAS was stable at about 600K left in cruise, which given the highly demanding combination of FSDT CYVR, Taxi2Gate KSEA, full ORBX down to PNW and a complex aircraft, seems to contradict my leak theory and rather show a randomness factor.

As a reminder, my last OOM's happened very fast, either while at the gate or after 15 minutes airborne.

[ahuimanu]

Very interesting observations about London. In some of my earlier posts, I have made the observation that flying into and out of the greater London area has been impossible using something like the Aerosoft A320 for me.

It is a shame that these VAS issues can't be addressed, but one wonders if the premise of Prepar3d suggests that actually flying long airline-style cross country sectors is outside of the aims (or capabilities) of the product. The traffic thing is interesting as it indicates that the BGL-based approach seems to have some issues.

I've been on P3D for 14 months (from 2.5 to 3.4) and the cost, not just monetary cost but opportunity cost, is appreciable as my preferred mode of simulation - heavy iron - is nearly a lost cause.

I've placated myself with some GA flying, but to no avail; I want to fly across the pond in airliners. However, It seems that there is something inherently unstable under the hood and VAS issues makes every experience unpredictable/unreliable. Nobody will long tolerate a 30-60 minute period of planning, preparation, and startup, just to have the flight fail along the route. For some of us, our use profile is the entire flight. I think of it as the line-oriented training that would occur in the airlines - let's do an entire flight, from start to finish. That seems to be off the menu or at least unreliable when we put it on the menu. To continue with the restaurant metaphors, I've found the need to "86" airliner work in P3D and, as a result, I find myself less frequently flying.

My observation is that Lockheed Martin gives these VAS topics a wide berth. I don't think they do so out of any other motivation than the variables in the problem are too great to offer any prescriptive solutions. The ecosystem is so complex, with backward compatibility still an aim of the product and an extensive SDK, that it is difficult to keep things together in the face of complexity.

Look at the latest version (3.4) and its principle new features: VR and Cinematic mode. Each are designed to increase visual immersion, a virtual sense of being there, as opposed to being features that increase operational/procedural immersion. A highly detailed airport scenery, or an airliner that performs like the "real thing," have not been the subject of any feature improvement that I can recall or detect. In my 14 months of prepar3d, my conclusion is that it offers the legacy of its predecessor (FSX/ESP) with improvements centered on visually improving the visual world model.

It would seem that we are simply asking too much of the underlying technology when we want to have high operational realism in the operation of complex vehicles - airliners are undoubtedly very complex machines - and high environmental realism - clouds, weather, elevation, country-side, airports, airport operations, traffic, etc.

This reminds me of the "coffin corner" in early jet airliners, where stall speeds and Mach limits would meet with often fatal outcomes. In Prepar3d, we have a lush visual world, and a lush simulated world, and their limits appear to have converged.

My guess is that for success in flying a PMDG 777 from KLAX to EGLL, you'll have to do this:

• Turn settings way down - likely all the way down
• Run no weather
• Run no environmental addons (no texture addons; no weather addons; no vector addons; no landclass addons, no elevations addons)
• Run no addon airport sceneries
• Run no traffic
• Run no navaids or facilities addons
• etc.

Effectively, just a operate with a bare bones install; it may not even be sufficient to turn areas off as they still may have installed something extra somewhere. Granted, while the Developer Network Showcase gives a contrary impression, many reports of end-user experience suggest that all of these addons can't be used at once.

In this addon game, to achieve "as real as it gets," there are few rules and no referees such that full utilization of the product list implied in the link I provided requires trial-and-error, confusion, and frustration on the part of the end user. Indeed, I am not certain any of Professional Plus licensees regularly post here such that we feel/hear their perspective. Are those of use licensing at the Academic and Professional level, whose use case is to simulate long flights in complex aircraft, an edge case?

I sure do miss legs like KLAX to EGLL and I just now realize that I've rarely successfully completed such a mission profile for the last 14 months.

[vmounier]

The coffin corner of simulation, I like that!

It is true that all sims seem to bank more on eye-candy building than on stability and performance improvement. Indeed, though, wouldn't pros require stability before they need pretty clouds?

And I also completely agree with your analysis of our huge investment, financial, intellectual and temporal in a simulator that requires more tweaking time that flying time. Maybe this should become a new type rating, the P3D-Settings Qualification. Requirement: 100 hours of live tweaking time a year. The check ride is posting a Youtube video or starting an Avsim thread...

All right, all jokes aside, I love P3D and having done a bit of real flying many years ago - I actually think if I ever manage to get back in the air, it will be thanks to P3D, period - I still routinely catch myself jaw dropped and drooling slightly while I watch the world go by from the sim's cockpit.

So I am going to keep testing, tweaking, finding a sweet spot, than throwing it all out the door and starting over as new issues arise, just because there I have been, and there I long to return. To my CFG file I mean.

For now, I am going to do some flying at OOMDB. Literally. I wonder if I have a VA(S) livery...

Cheers,

Vince

[ahuimanu]

The coffin corner of simulation, I like that!
...

For now, I am going to do some flying at OOMDB. Literally. I wonder if I have a VA(S) livery...

Very punny.

[Beau Hollis]

Thanks everyone for your detailed feedback. We appreciate the time and energy spent testing, tweaking, and reporting. Memory management and performance is important to us, and we appreciate any information that may help us track down how platform improvements may affect memory usage patterns when multiple complex add-on products are used in combination.

Isolated examples of how a specific setting, action, or addon affect VAS are especially useful. Advanced profiling and optimization of add-ons is difficult for us, because many don't function properly with our development builds. If you can catch a noticeable difference in VAS with default content (even if not large enough to cause an OOM), that too can be extremely useful.

[downscc]

Beau, I noticed something interesting related to VAS on last test flight.

The session was started with a pre-saved scenario in position for takeoff and VAS remaining was 1255 MB before cycling views (ie locked spot, tower, etc., as well as internally different cameras or view in the VC) and this time I did not cycle views.

The VAS remaining stayed unusually high, above 1100 MB when I normally see a range of 600-900 MB, for five hours. I am starting another session now with same "no view changes" conditions to repeat.

Unfortunately, that 5 hr session was ended by Windows due to an error with the stackhash module, gotta be related to the Windows10 update so is different issue that I'll be able to solve. I'll keep on testing this "no view change"

[vmounier]

I remember messing with UseGlobalTerrainView=True a while back, but I'm pretty sure I reset to default after that (I'm not at that computer now). I don't know if that could affect VAS positively or negatively but it does have to do with cameras. One thing is for sure, until a few days ago when I started playing with Cinematographer mode, all my view switches were within the EZDok camera list, not P3D's various cameras.

I will do the same test (switching views vs not switching at all on a given saved flight) albeit on a much shorter session, and report. I also want to try an figure if after having gone through a full set of views, I can keep spending VAS by going through another cycle of the same views, which I think was the case but doesn't make much sense.

[nealmac]

I think part of the problem with flying out of London is the 5000 and 6000 ft altitude restrictions. Flying at such a low altitude for extended periods causes a lot of scenery to load at a high resolution, until your system can't handle any more.

[cannow]

Thank you Beau for your reply and totally understand the difficulty around this subject . Will try to get differences between versions 3.2 against 3.4 with stock P3D around London my personal trouble hotspot to illustrate my point and also the memory required for some of my add ons . I am quite sure I will never OOM with stock but the higher the LM base the easier it will be with complex add ons to fall over even with careful management . Any advice you can give re VAS release during flight would be most useful. P 3D I know can do it but find most of the time the drop is very small and certainly not enough to clear out any heavy payware airport I started from. A restart is all I can do then VAS becomes manageable . I never activate more than the arrival and destination airport .

[downscc]

Beau, I followed up on the interesting observation that I had when not changing views from VC Capt position. Completed a 14 hr B77W trip FSDT KLAX to FlyTampa YSSY with lots of weather. VAS remaining never decreased below 1150 MB until landing and then only down to 950 MB..., actually better than v3.3.5.

After installing v3.4 client, I noticed the views as I cycled through cameras with the S key included the Occulus views and I didn't like that..., I will probably never use a VR headset until there is something in the cockpit that resembles an EFB...anyway: I remarked out the occulus view (using the ; char) when I started using v3.4. I saw another thread that reported problems doing this so I deleted the camera.cfg file in appdata\roaming and let P3D rebuild a new one. I noticed the new one that P3D built didn't inlcude occulus camera definitions.

I flew the long trip with the camera.cfg file rebuilt by P3D without any VAS issues, whereas before I was having serious VAS issues on every trip. Hope this helps.

[Beau Hollis]

Thanks for the report. Can everyone else please clear their cameras cfg and report back if that also helps. We made a number of changes to how VR views work internally, and they new camera definitions use a cfg option to hide them from the menu and key cycle. If a headset is detected, our VR plugin will detect it and create instances of the VR cameras.

On a more general note, I believe the primary reason for increased memory hits from view cycling is that the external aircraft model is typically a separate model from the VC. The user aircraft models won't page out of memory the way air traffic might because you're always near the user aircraft. So, once you've requested both the external and internal model, both models and their related textures, materials, and effects will stay in memory.

[abd40110a]

I do the same thing, clear the occulus definitions from the camera.cfg, and the VAS does not change from view cycling.

[lkalam]

On a more general note, I believe the primary reason for increased memory hits from view cycling is that the external aircraft model is typically a separate model from the VC. The user aircraft models won't page out of memory the way air traffic might because you're always near the user aircraft. So, once you've requested both the external and internal model, both models and their related textures, materials, and effects will stay in memory.

Beau,

just to clarify - wouldn't it be possible to page out the external model and related textures, materials and effects as long as the user has returned to an internal view (cockpit / VC) after a certain time has passed?