Sign in to follow this  
McDaniel

OOM Emergency procedure....(by far not a solution!)

Recommended Posts

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

 

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

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

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.

Share this post


Link to post

 

 


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

Share this post


Link to post

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

Share this post


Link to post

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 :lol:

Share this post


Link to post

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. 

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Rob a quick way to OOM is to fly out of KRNT with a plane like the Carenado Hawker in Orbx PNW and head toward Orbx KBVS, 74S and Jefferson county I promise they will OOM before they get to 30,000 about 10 min. Also Rob I'll be happy to guinea pig if they need someone to make the sim OOM and send them data. 

Share this post


Link to post

Well I think LM or 3rd party vendors have succeeded in ensuring no entertainment will be had with P3D.  Tried lowering settings with previous mentioned flight, OOM once again on approach to Copenhagen.  Right at the bridge...I think I'm going to jump off that bridge.

 

OOM=the condom of P3D....protecting you from any illegal flightsim entertainment!  Hope I don't get in trouble for saying that.....

Share this post


Link to post

If true, its good news that LM is addressing this issue.

 

Frankly, I strongly disagree with those claiming that its not the responsibility of LM to reduce VAS usage or find means to work around it. When they advertise their product on their home-page, they additionally advertise in concert with FTX Region products and planes (showcase). They even showcase the PMDG 777 and FlyTampa Copenhagen, two well known add-ons that eat VAS for breakfast, lunch and dinner. Even sometimes, their showcase images are packed with autogen as well, which unfortunately is not an option for most simmers using PMDG products and add-on airports.

Share this post


Link to post

I have decided to lock this topic as the topic has been discussed more than enough here in this forum and elsewhere and leads us nowhere.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this