I would suggest turning on gauge debugging in the Prepar3D.cfg and either fix the errors or avoid using any content that pop up alerts until the next patch.

"... until the next patch." To me, that indicates a fix in the works.

 

Hook

"... until the next patch." To me, that indicates a fix in the works.

 

Hook

 

I'll admit I totally missed that part. I'll still wait to see how Prepar3D 2.2 turns out though, there's tons of other stuff that has to be fixed.

I'll still wait to see how Prepar3D 2.2 turns out though, there's tons of other stuff that has to be fixed.

They fixed tons of stuff in 2.1, is there any reason to believe that 2.2 will be any different? Relax, they'll let us know when they get a list of fixes that they're happy with. Right now that list may be in constant change.

 

Hook

They fixed tons of stuff in 2.1, is there any reason to believe that 2.2 will be any different? Relax, they'll let us know when they get a list of fixes that they're happy with. Right now that list may be in constant change.

 

Hook

 

Firstly, 2.1 fixed lots of issues but introduced a lot more. I'm trying not to be pessimistic, but I won't be surprised if 2.2 (which is supposed to deliver CrossFire/SLI support and cloud shadows) is just the same.

 

Secondly, I just don't like how they're blaming aircraft speeds for bad autogen paging that cause OOMs. In FSX, 1.4 and 2.0, this issue didn't matter at all (and is it really an issue and not something Beau made up?), and he's saying it as if it's our own problem for flying at specific speeds.

 

I'll call Prepar3D 2.x a success when it has reached a point where memory management is in better state compared to FSX. When they've got a product running on a DX11 engine (which has much less overhead than DX9) and when they claim that they have improved the way the memory management system releases clutter, they've really got no excuse. I'm willing to give them as much time as they need, but they need to prove that they can do something. Those frustrating responses only make matters worse.

ChaoticBeauty, I gave a "Disagree" to your last post, but unlike most I'll state my reason for doing so.

 

Honestly, you've made your position clear. In fact, it's a position with which I cannot honestly disagree. However, how is it at all useful to continue restating the same thing over and over again, ad infinitum?

 

After the first time, it just becomes more "noise..."

ChaoticBeauty, I gave a "Disagree" to your last post, but unlike most I'll state my reason for doing so.

 

Honestly, you've made your position clear. In fact, it's a position with which I cannot honestly disagree. However, how is it at all useful to continue restating the same thing over and over again, ad infinitum?

 

After the first time, it just becomes more "noise..."

 

"Disagree" means that you disagree with what I say. If you don't like my post, there's the "Dislike" rating.

 

LHookins made a question (why I believe 2.2 might not fix the problems) and I answered it. If you think my posts are boring, then just ignore them. There's honestly other, more significant noise in this forum that you should actually be taking care of.

Hi all

 

"Velly interesting"

 

I have just taken a couple of hours to read through this entire thread, and I am very glad I did.

I want to thank all the "testers" for their time and effort and all the information gathering done by others.

I was going "nuts" trying to decide what could be causing my OOM so quickly, but with this new found knowledge I will sleep well tonight!

 

Once again thanks guys.

 

Regards Clive.

 

I'm still working on this one project, but already I've eliminated most of the "syntax errors". The remaining few are turning out to be stubborn, as the reported error text is obtuse as hell! I'll keep plugging away though until I wind up with a totally "clean report," meaning a totally blank ContentErrorLog.txt file!

 

 

I've had that option turned on for P3d since I installed version 2.1 and I have never seen anything written to it except this:

 

Mission Warning: One instance of ScenarioMetaData required.

 

 

I have 15 non-default aircraft installed and I've flown them all at one point or another with version 2.1.

 

Maybe everybody should turn the XML error-checking option on and see what they find.

Allready got a refund for this piece of crap, they like to call software...

 

I mean do you realize that we pay 60 dollars or more for a software we can´t use ?!

I´m not able to fly longer than 30 minutes in dense areas. What the ######...

 

They are not able to deliver an at least working ! product...

 

Reinstalled fsx...

 

 

I don´t think p3d will be a serious alternative for a long time

 

 

bad autogen paging that cause OOMs. In FSX,

 

How have you reached a decision that the autogen paging is "bad", or that memory management in 2.1 is faulty? Just asking if you can present some of your own test data / reasoning that shows this definitively.

 

Yes LM have said they will look into possible Veg autogen paging errors as a matter of urgency, to see if any "improvements" can be made, but that is not the same as saying their definitely are paging issues.

 

V2.1 is very useable for me if I rein myself in on autogen settings.

 

Rob

But they just don't seem aware that Prepar3D 2.1 is completely broken!

 

They are aware, I can assure you.  But to give you an idea of the challenges ... P3DV2.x is a threaded application, it's also a "time critical" application ... when issues arise because of changes, they are VERY difficult to track down.

 

Consider this, suppose there are 20 threads (for example) working on tasks in real time, they are all related yet independently running ... one of those tasks seems to be causing a problem.  How do you go about "debugging" that single task ... stopping the code during execution could invalidate the other tasks or even mask the cause of the problem.  So what are programmers options, there are several, but if one suspects it is a thread synchronization/timing issue then a choice (not the only one) would be to write out state values to files or out to a common shared memory location .. however, this action in itself can adjust the timing in such a way that the problem doesn't manifest itself. So what do programmers do then, we use a 2nd PC to remotely monitor the executing of the application on the main PC ... the process is extremely time consuming and difficult to setup and manage.

 

Now, I'm not saying this IS what's happening in P3DV2 or how LM are proceeding, but I am trying to give you some insight to the complexity of an real-time threaded flight simulator.  I would suggest you try to find some patience in the process ... LM engineers are not talking crap.  

 

And yes, they are going to break backwards compatibility, I can't think of a new version of FS series that hasn't broken some degree of compatibility.

 

Cheers, Rob.

Edited February 23, 201412 yr by Guest

 

 

Firstly, 2.1 fixed lots of issues but introduced a lot more. I'm trying not to be pessimistic, but I won't be surprised if 2.2 (which is supposed to deliver CrossFire/SLI support and cloud shadows) is just the same.

 

I think LM should really aim to do smaller patches more frequently to try to contain the chaos that ensues from changing too many things at the same time.  Maybe this is especially important P3D 2.x.

How have you reached a decision that the autogen paging is "bad", or that memory management in 2.1 is faulty? Just asking if you can present some of your own test data / reasoning that shows this definitively.

 

Yes LM have said they will look into possible Veg autogen paging errors as a matter of urgency, to see if any "improvements" can be made, but that is not the same as saying their definitely are paging issues.

 

V2.1 is very useable for me if I rein myself in on autogen settings.

 

Rob

 

Lockheed Martin said that the autogen paging is bad when flying at specific speeds.

 

 

Lockheed Martin said that the autogen paging is bad when flying at specific speeds.

 

This is true for FSX also ... they were probably referencing Word Not Allowed's comments about flying at 1100 Kts @ 500 ft AGL.

 

AutoGen seems to load considerably faster than terrain textures (and the pop free approach is 1000X better than the old FSX way).  The layer process (this exists specifically for 3rd party content providers, otherwise it would not exist because it has performance implications) and having to decide "who's on first" (what we see) isn't optimized for performance, it's optimized for flexibility for 3rd party content.    

 

In FSX, if I enabled all my MSE scenery layers, the texture system just couldn't cope (I demonstrated this in a video) ... constant state of low quality textures (blurries).  I had to select my scenery very carefully and ONLY what I needed ... and it wouldn't take much to overload the terrain system.  This process hasn't changed in P3DV2.x, same layer system to retain a level of backwards compatibility.  If LM did away with this system because it does have real performance limitations, then all 3rd party scenery, airports would no longer work.

 

Cheers, Rob.

Here is a helpful tool for monitoring VAS, more specifically what does what and when and where and why ... it's called VMMap http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

 

The supporting help file provides good information about the supported allocation types:

 

Image

The memory represents an executable file such as a .exe or .dll and has been loaded into a process by the image loader. It does not include images mapped as data files, which would be included in the Mapped File memory type. Image mappings can include shareable memory like code. When data regions, like initialized data, is modified, additional private memory is created in the process. The Details column shows the file's path.

 

Private

Private memory is memory allocated by VirtualAlloc and not suballocated either by the Heap Manager or the .NET run time. It cannot be shared with other processes, is charged against the system commit limit, and typically contains application data. 

 

Shareable

Shareable memory is memory that can be shared with other processes, is backed by the paging file (if present), is charged against the system commit limit and typically contains data shared between DLLs in different processes or inter-process communication messages. The Windows APIs refer to this type of memory as pagefile-backed sections. 

 

Mapped File

The memory is shareable and represents a file on disk. The Details column shows the file's path. Mapped files typically contain application data.

 

Heap

Heaps represent private memory managed by the user-mode heap manager and, like the Private memory type, is charged against the system commit limit and contains application data. Application memory allocations using the C runtime malloc library, HeapAlloc and LocalAlloc, use Heap memory.

 

Managed Heap

Managed heap represents private memory that's allocated and used by the .NET garbage collector and, like the Private memory type, is charged against the system commit limit and contains application data. 

 

Stack

Stacks are private memory used to store function parameters, local function variables and function invocation records for individual threads. Stacks are charged agains the commit limit and typically grow on demand.

 

System

System memory is private kernel-mode physical memory associated with the process. The vast majority of System memory consists of the process page tables.

 

Free

Free memory regions are spaces in the process address space that are not allocated.

 

Note: The VirtualProtect API can change the protections of any page to something different than that implied by the original allocation's memory type. That means that there can potentially be pages of memory private to the process in a shareable memory region, for instance, because the region was created as a pagefile-backed section, but then the application changed the protection on some pages to copy-on-write and modified them. The protection shown for a region isn't necessarily the protection it had since it's creation. 

 

Here is a image of the tool at work on Prepar3D.exe: 

 

 

And here is a really good article around some of the issues of memory management: http://bugslasher.net/2011/01/15/memory-exhaustion-even-if-a-large-enough-free-memory-segment-is-available/

 

Personally, it's very clear what needs to happen -- it needs to be 64bit.  Yes I know I waive this flag a lot, but when I hear stuff about LM programmers being incompetent and not knowing what they're doing and the endless threads on OOMs and VAS usage and knowing LM are bound by a 32bit ESP ... so in the meantime I will continue to waive the 64bit flag in eternal hope this happens sooner.  

 

Cheers, Rob.