Ok guys....yes I push the limit, as always if I do something... :-)

 

I love to fly with medium to high settings, also I love flying the mighty 777 from the company with the big manuals...

 

Sometimes I get the unfriendly bing bing from windows, most of the times on final...so here comes the emergency procedure which in my case let me finish my flight without the OOM crash....

 

Step 1: Go to the graphics menu

Step 2: Set global textures to 512

Step 3 : End your flight and be happy...

 

I know its stupid and "shurely" not a solution, but for me it works, since the OOM emergency procedure, I can finish flights, also in demanding airports!

 

Just try, next time you hear the bing bing.....maybe it works for you too...

 

McDan out

Hi McDan

 

That's a technique I've used in the past and it does indeed work for many case (but not all).  One key element is having enough memory left so you can access the graphics options ... not always the case.  

 

OOM emergency tips:

 

1.  If very close to OOM, pan the view up to a spot that has no gauges or any high detailed graphics (may free up enough VAS to access menu and save the flight)

2.  If you have enough memory left to access the menu (Options | Display) and set Textures to 512 ... if the menu doesn't show any text (all gray) then it might be too late ...

3.  Pause the sim, run AI Traffic Manager and set it to 1 ... this will eliminate most of the AI traffic and free up some VAS

4.  Do NOT repeat access to the Scenery Library (this will consume 44MB per access even if you make NO changes)

5.  Be aware if you have never accessed the menus at all during your P3D session/flight, your first menu access (only first one) will consume about 80MB

 

I have brought up the VAS/Memory issues to LM (a couple of times now) that seems to be more prevalent in V2.5 12945 than prior versions.  I've provided procedures to replicate on a base (no-add on) P3D V2.5 12945 and LM have acknowledged they are looking into it.  Adam has also posted on the OOM thread over on LM's forums indicating the same (http://www.prepar3d.com/forum-5/topic/oom-in-2-5/page/13/).  LM are definitely aware, lets hope they can find something and provide a solution.

 

Cheers, Rob.

 

 

I have brought up the VAS/Memory issues to LM (a couple of times now) that seems to be more prevalent in V2.5 12945 than prior versions.

 

This is what I've found as well and have posted about elsewhere. I'm glad to see that this is recognized and not a one-off.  I'm sure it will soon be addressed by LM. 

 

In the meantime, yesterday I reverted my setup to the previous Hot Fix ending in 44 and I've got my VAS cushion back. I only wish I'd done this a month ago.

 

Robert

Thanks for all you do for us, Rob! This OOM stuff is killing us!

I have FSUIPC record over a same-name situation every 160 seconds

 

this same name is my default situation.

 

Since I have everything on SSD it does not take long to reload it all from the beginning

 

 

BUT I have been having luck lately simply disabling the outside model, getting even closer to real life when i never fly "outside" anyway

LM dev team is working on it and trying to duplicate ... I'm helping them come up with ways to duplicate using no add-ons -- which is not easy.

 

It can be an extremely difficult issue to identify because of threading (multi-core) and the "debug" environment is not exactly the same as a release environment.

 

I've also asked for additional tools that end users might be able to use to diagnose issue over the very wide array of 3rd party products ... fingers crossed.

 

Cheers, Rob. 

I really hope they can find a way to improve VAS handling ...

 

Today I did a 1.5h flight and everything was great till I descended below 10.000 ft.....OOM...

I missed those last 10 minutes.

 

Especially today when I was testing my new flaps gauge...

Gerard - I feel your pain.

 

Rob - thanks again for what you do for us. I'm pretty sure I speak for a few folks - if there is anything we can do to help let us know.

Thanks for the tip, I'll have to try this next time.  

 

Last night I was near the end of a dusk flight from EDDL(Aerosoft)-EKCH(FlyTampa) with PMDG 777.  Set up for perfect ILS approach RWY30 (Oresund bridge to my right, really cool) with RC4, and WHAM!!! the OOM message appears. Well at least I got to see the end of the runway in sight, ha!

 

I'm going to try same flight tonight with adjustments to LOD(6.5 to 4.5) / ASN (5 cloud layers to 3) / autogen (dense to normal).

Thanks Rob much appreciated. Im sure its not going to be an easy task.

 

Gerard, know the feeling well. I started a three hour flight today EGKK - LDSP first attempt was one of those where you spend 30-40 min doing all the preflight. Once I was in the air and over the chanel the sim stuttered, frames went down to 3-4 and as I lurched for the ALT key to turn on the menu bang I'd OOM'ed. At the weekend I'd loaded the new freeware Europe mesh and was using slightly higher settings in that I'd turned on ground shadows.

 

Turned the shadows off and turned autogen right down and tried again. This time the flight was successful but on approach to Split (the default airport) at about 2000ft I got the ding dong of death but managed to land phew!

 

Time to make some choices and revisit settings for those long haul flights. The frustration of missing those last ten minutes can be averted by missing out on some other stuff I'm sure. Descisions, Descisions.

Even if LM can't replicate the issue, I'm hoping (ok begging) they'll provide us with some tools that can help validate BGLs and/or something to pin point the cause (some sort of logging) similar to simconnect's ability to log events but is more focused on BGLs and tracking what gets loaded and unloaded and how memory is being allocated and de-allocated.  Enable it via some sorta of .cfg entry and/or command line on prepar3d.exe.

 

Cheers, Rob.

Fantastic pots#2, Rob. Learned a bit there about VAS depletion which as the OP alluded to, generally happens to me in the closing stages of a flight using the 737NGX.

 

Hope between you and LM,somebody gets a rope around this.

 

 

Rob - thanks again for what you do for us. I'm pretty sure I speak for a few folks - if there is anything we can do to help let us know.

+++1, well said.

LM are trying ... they've even loaded up some 3rd party add-ons to do more testing in an attempt to replicate ... which is definitely well beyond my expectations.  

 

So we'll see what happens ... I know this must be incredibly time consuming for them given the time it can take before one hits an OOM.  To effectively understand memory issues, LM will need to be able to break (as in debug/stop execution but keeping the code loaded) the code just before the OOM ... that in itself requires considerable work in setup/prep as they'll need to do several "long runs" to get to that point and each time they restart, they'll have to repeat the long wait.

 

I've provided a few scenarios where I think/hope they can duplicate with "add-ons" in just 5-10 minutes ... hopefully reducing the long wait.  The other NO add-on scenario took about 2 hours before hitting OOM.

 

Having done this type of debugging before in other non-fs related products, it's definitely NO FUN ... LM would have to setup a separate dev PC running so they can continue to do their own regular v3 "work" ... can't have senior programmers sitting around all day waiting for break points to trigger.

 

Cheers, Rob.

You can speed up the OOM process by slewing fast over large cities.

I can cause an OOM generally within 5 mins (maybe less) if I wanted to.

But Rob, on the plus side imagine what kudos they'd gain if they spent all that time chasing OOMs and managed to write the code that would realise a sim that did not OOM. It'd be a massive boost in sales, simmers abandoning the dead-in-the-water past-its-sell-by-date MSFS in their droves.