P3D "Out of Memory"

[MikeT707 1,181]

 

 

Hi Mike, yeah I read that, I think the warning at the end suggesting it could be "expensive" is steering me clear.  I think right now I'd rather have an OOM free experience ... plus there are some products due out that I want and I know they will stress out VAS also (FSGRW and the FTX OpenLC products).

It would be require a higher resource allocation if you increased the density from a default value of 2 to an even denser value of 1.  However, the resource allocation would be lower if you decreased the density from a default value of 2 to a less dense value of 3, 4, 5, or any integer up to 9.

From what I understand, a user could set an autogen slider value to Very Dense and then lower the density incrementally from there by changing the value from a 2 to a 3.  This config parameter seems to give us users the ability to adjust autogen density in more granular steps than going from Dense to Very Dense to Extremely Dense.  Thoughts sir?

[Noel 4,507]

 

 

I have no idea what LM's funding situation is ... but whatever the reason, the same decision was made (to not provide a 64bit path) 8 years ago with Microsoft/Aces.

 

Yes but they're made some positive (or at least not exclusionary) reference to 64-bit without a hard target date and they will get there because they have to, and I would argue they not it, but are looking at their big picture and for the work it will take to not only develop the engine but to work w/ 3PDs they may just not have the staff time to devote while at the same time improving P3D in its version 2 form.   Don't forget if they can resolve a few more bugs and improved memory management you have a platform already that could do quite well even at 32-bit.  I simply have no idea how much memory management optimization potential there is in V2.  If it's considerable then that can push the 64-bit environment out a few years and in doing so allow excellent use of add ons coming from FSX.  My guess is they've thought this thru quite well and concluded this was the best path for their resources to handle.  Bad decision?  Hard to say for me.

[Guest]

I agree with, P3DV2 does have A LOT of bugs and it would be better to get those sorted out before "adding" a 64bit path.

 

Ran into this bug tonight, was trying to change IFR flight destination airport mid flight and got this error (Event Viewer):

 

Faulting application name: Prepar3D.exe, version: 2.0.9448.0, time stamp: 0x528edbe6

Faulting module name: uiInterface.dll, version: 2.0.9448.0, time stamp: 0x528edbd9

Exception code: 0xc0000005

Fault offset: 0x0000ccd7

Faulting process id: 0x1a40

Faulting application start time: 0x01cf0e8b2cc36376

Faulting application path: V:\Lockheed Martin\Prepar3D v2\Prepar3D.exe

Faulting module path: V:\Lockheed Martin\Prepar3D v2\uiInterface.dll

Report Id: 3f2732d5-7a82-11e3-ad13-c86000138c63

 

Also for some reason ATC were directing me far far far away from my destination airport ... not sure what was going on there (GPS direct) but after 100+ miles heading in the wrong direction (completely opposite) I figured something was not right.

 

I wouldn't and hope I'm not saying "bad decision" ... just a decision I'm not sure I understand after watching 8 years of fellow flight simmers in regular frustration with OOMs.  DX11 is certainly more efficient, but it can't work miracles.

 

 

This config parameter seems to give us users the ability to adjust autogen density in more granular steps than going from Dense to Very Dense to Extremely Dense.  Thoughts sir?

 

Hmmm ... my thoughts will be to try this AFTER we get the first patch from LM ... I'd like to see how the patch works first.

[simmerhead 885]

I agree with, P3DV2 does have A LOT of bugs and it would be better to get those sorted out before "adding" a 64bit path.

 

Ran into this bug tonight, was trying to change IFR flight destination airport mid flight and got this error (Event Viewer):

 

Faulting application name: Prepar3D.exe, version: 2.0.9448.0, time stamp: 0x528edbe6

Faulting module name: uiInterface.dll, version: 2.0.9448.0, time stamp: 0x528edbd9

Exception code: 0xc0000005

Fault offset: 0x0000ccd7

Faulting process id: 0x1a40

Faulting application start time: 0x01cf0e8b2cc36376

Faulting application path: V:\Lockheed Martin\Prepar3D v2\Prepar3D.exe

Faulting module path: V:\Lockheed Martin\Prepar3D v2\uiInterface.dll

Report Id: 3f2732d5-7a82-11e3-ad13-c86000138c63

 

Also for some reason ATC were directing me far far far away from my destination airport ... not sure what was going on there (GPS direct) but after 100+ miles heading in the wrong direction (completely opposite) I figured something was not right.

 

 

Rob, that is a known bug. Flight planner and IFR flight is broken. I've reported the uiinterface.dll crash to LM a good while ago.

[mgh 89]

Why would they be different?

Because I, for one, would be expecting something better than FSX/FS9... for my money that didn't have its faults and flaws.

 

I can no longer recall the link so may be wrong, but my understanding is that FS10 would have broken backwards compatibility. Perhaps some one could confirm or deny this?

[HiFlyer 9,363]

Because I, for one, would be expecting something better than FSX/FS9... for my money that didn't have its faults and flaws.I can no longer recall the link so may be wrong, but my understanding is that FS10 would have broken backwards compatibility. Perhaps some one could confirm or deny this?

http://blogs.msdn.com/b/ptaylor/archive/2007/10/02/acceleration-and-sp2.aspx

[mgh 89]

Thank you

 

1) From a feature perspective, we do not match the magic screenies item-for-item because those screenies ignored an important visual element—the aircraft. We added virtual cockpit shadows to the work list because this feature further enhances the immersion. Of course, we also faced schedule and other constraints.

 

2) We are not promising runtime backwards compatibility in the current DX10 code path now or in the future. This is for two reasons:

 

a)The first is to send a message that we are going to change the backwards compatibility story moving forwards.

 

b)The second is practical, in that continuing to provide the backwards compatibility we do is a huge drag on forward progress. Spending time on 4 or more code paths (FSX DX10, FSX DX9, FS2004, pre-FS2004) costs us time that could be spent polishing the existing features, working on resource management to fully eliminate out of memory errors, and working on performance. We have to change that balance and in the DX10 preview you can see the first notice of that. Yes, we know we have to address some features that are not possible using the FSX SDK in future SDKs so that 3rd party developers are enabled and do not depend on these old techniques and we accept that

And the last post in that that thread is dated 24 Jun 2008.

[Arwen 289]

 

 

Also for some reason ATC were directing me far far far away from my destination airport ... not sure what was going on there (GPS direct) but after 100+ miles heading in the wrong direction (completely opposite) I figured something was not right.

I've been running into this same ATC issue lately . . . and it never happened (to this degree, and consistency) until just a few days ago.

The ONLY two things I have changed or done differently in the past few days are:

1.) Edited my Prepar3D.cfg: changed AffinityMask=14 to AffinityMask=252

2.) Began starting Prepar3d in Window mode, with Scenario Setup's "Show at Startup" checked". And I may have also set up my Flight Plan before hitting ALT-Enter, and going to 'full screen' mode.

 

So my guess is one of the above is somehow causing the ATC to lose focus.  

I also found that opening the Map view will sometimes 'wake up' the ATC, so that it becomes aware of my current off-course location, and then redirects me.  But I have also found that this can cause the IFR to become cancelled, but then 'request IFR clearance' seems to fix it and I am directed correctly ('correctly' within the limitations of the default ATC].

[RTK1972 288]

Heads up Gentlemen...

 

I am not 100% sure but did tha last test different setup scenarios that all ended with an oom approaching uk2000 egll (even orbx england and eghi installed).

Those OOM'S appear mostly at 2.9 Gbyte VAS. FSX was able to push it to 3.2 sometimes 3.3 before running into an OOM.

So i was thinking about the Highmemfix tweak.

 

after putting that into prepar3d.cfg

 

i got NO OOM crash when flying the same approach and cruising above EGLL. VAS is at 3.1 Gbyte..

 

Could you try it too and report back if it works for you please ?

 

Thanks a lot,

 

Carsten

[Guest]

 

 

but my understanding is that FS10 would have broken backwards compatibility.

 

Not really sure what you are getting at Gerry?  Can you expand?  It sounds like you are suggesting that P3DV2 needs to retain compatibility with very old legacy products FS9 and earlier?  I don't have any of those products (I do, but not installed, buried away on an archived HD somewhere) so I can't test, but my understanding is legacy (FS9 or earlier) products don't work well in P3DV2 (compatibility will depend on the product and what it does).

 

If your expectations are to bring forward a compatibility path for very old legacy products, then I'm affraid that probably isn't going to happen (regardless of 32bit or 64bit) for the very same reason's Phil Taylor pointed out.  However, because we now have a continued development process for ESP, I wouldn't rule out the possibility of LM (less likely) or some enterprising 3rd party content provider (more likely) to offer a tool that will convert (as best it can) legacy products to be at least compatible even if not as visually pleasing as newer offerings (if the demand is there).

 

Not going to 2nd guess anyone's expectations ... some of my expectations were met, some exceeded, some not, but overall what's been delivered feels like progress and most importantly a patch is due out this month with further patches due out during the year.  FSX has/had many of the same faults over it's original release thru SP1 and then SP2.

 

The benefit of dual 32bit and 64bit paths in a single code base is to ensure compatibility with products that use 32bit DLLs and to ensure growth and scalability in a 64bit future.  I don't think anyone wants to spend another 8 years playing the OOM shuffle to the symphonic sounds of frustration B side mix   Both 32bit and 64bit will give people (users and 3rd party) time to move onward and upwards and really progress the flight simulation experience.  Just think of the possibilities that would be open to 3rd party content providers if they didn't have to continually be concerned about VAS -- not to mention less support needed.  Content providers now, appear to go to great lengths and all kinds of hoops (configuration tools to turn on/off airport scenery elements, tools for managing texture sizes, etc. etc.) -- I'm pretty sure content providers/developers don't want to have to code such tools, but they know it's necessary given VAS restrictions -- a 64bit path would alleviate the need for those tools (and many other compromises).

 

 

 

Flight planner and IFR flight is broken. I've reported the uiinterface.dll crash to LM a good while ago.

 

Ah, ok, figure that was probably the case.  Thanks!

 

 

So i was thinking about the Highmemfix tweak.
 
after putting that into prepar3d.cfg
 
i got NO OOM crash when flying the same approach and cruising above EGLL. VAS is at 3.1 Gbyte..

 

Pretty sure that "fix" was no longer needed in P3D going back to atleast version 1.3.  If I were to hazard a guess, I think you just managed to avoid whatever it was that caused the OOM in the first flight ... a simple view rotation (even slight one) within the VC has triggered the sudden VAS change on my setup ... so sometimes the same flight/approach will trigger an OOM, sometimes not.

 

But even at my new AutoGen = Dense (building and vegetation) I can still trigger OOM if I use 3 cloud layers (at only 90mi draw distance) ... which is going to be a problem when/if FSGRW comes out for P3DV2.  Sadly, I have to keep reducing and reducing and reducing visual quality ... I'll admit, not a great situation.  But lets see if the patch address any of these VAS issues ... at least there is going to be a patch.

[Syonco 13]

I thought the highmem fix was in by default? I guess not.. Will try it out and report back.

[RTK1972 288]

on Dear, i think ROb is right... Thare must be something else that prevented be of the OOM....

 

i hate this trial and error.

[mgh 89]

Data files, BGL, AGN, DDS, BMP, etc. shouldn't require any modifications.

 

Many of those files contain legacy code which date back to FSX/FS9. Of course it would be possible to retain them but even Microsoft accepted there was a need to advance back in 2008. The must surely come it's necessary to bite the backwards compatibility bullet.

[Syonco 13]

on Dear, i think ROb is right... Thare must be something else that prevented be of the OOM....

 

i hate this trial and error.

Yep, afraid it was something else. Searching for what causes the OOM's, in my i've found it to be an impossible task. Sometimes i'm able to fly a short 20 min route just fine. Next attempt with the exact same settings / weather it can crash as soon as i take off, even during taxi. For now it's back to FSX which not only looks better in my case (ENB etc) but is actually stable with every slider maxed out. Only thing P3D holds over FSX for me is the FPS increase. 

 

We'll see what happens over the next few months.

[Guest]

 

 

Many of those files contain legacy code which date back to FSX/FS9.

 

Just data in a file, how the application deals with the data it reads is entirely up to the developer -- no need to change the data layout or structure of those files be it a 32bit or 64bit process and any legacy elements in the data can just be ignored.  

 

Once LM sort out the code (again, single code base) to deal with the allocation differences (types, max values, etc.) ... setup two targets (x86 and x64), build for each target and publish for each target.

 

IMHO, moving to DX11 and all the other code cleanup work they did is a more challenging task than having to code a 32bit and 64bit path.