No, it's an accusation, since you categorically pinned the problems you're experiencing, at PMDG and proclaiming that it's - without a doubt (in your mind) - their fault for the crashes.

 

The fault is always the 32bit simulator. There is only room for a couple of heavy addons before the system chokes. If you get an OOM, you remove some scenery or something else and try again.

If just one of the test subjects change and the crash occurs, then obiously the changed subject must be the cause....seems logical to me.

 

Seems so but there are many other moving pieces.  Could be your video driver, couatl engine, etc.  Correlation does not prove causation, it is merely a part of the troubleshooting process. First step is define the problem. Get data.

 

There has been a lot of users at the new EHAM with their shiny new B744.

The fault is always the 32bit simulator. There is only room for a couple of heavy addons before the system chokes. If you get an OOM, you remove some scenery or something else and try again.

 

Hmm - well...

 

If something leaks memory inside the simulator, and the simulator crashes due to an OOM, the problem does not reside with the simulator. The problem - in that case - points towards component leaking the memory. The simulator can only act as is does, due to the memory limitation, but that does not makes it the simulators fault.

 

Hope that was (somewhat) clear...

We did extensive testing during beta to identify and eliminate memory leaks, and those findings will find their way into the other products.

 

If you can document a repeatable memory leak then by all means put it on a trouble ticket and submit it.

Hmm - well...

 

If something leaks memory inside the simulator, and the simulator crashes due to an OOM, the problem does not reside with the simulator. The problem - in that case - points towards component leaking the memory. The simulator can only act as is does, due to the memory limitation, but that does not makes it the simulators fault.

 

Hope that was (somewhat) clear...

 

However, in most cases with a 64bit program, minor memory leaks would not cause an OOM because you're not hovering just under the memory limit. As the addons become more complex, you will push toward that threshold even more and thus reduce the tolerance. Regardless of how you put it, the simulator plays a big part in the issue. I'm willing to bet that FSX and P3D generate (by far) the most forum threads related to OOM's in the whole world.

 

Of course it could be that every addon and driver that I use in another 64bit simulator is perfect and that's why I never get OOM's.  :wink:

 

Developers should definitely put effort into testing their code for memory leaks, they aren't good and you shouldn't just dismiss it because memory is abundant. However, these program, drivers etc are all very complicated and it's likely going to happen. It would keep the end user experience so much better to have a buffer in place. Onward and upward.

 

 

I'm willing to bet that FSX and P3D generate (by far) the most forum threads related to OOM's in the whole world.

 

I bet that is a safe assumption.  In my very limited understanding, there is a problem with how well the C++ destructor works.  A friend suspects that Microsoft is much more interested in us all drinking the C# and .NET koolaid so it is intentionally buggy.

Pretty much I have similar configuration and software installed ,after read in Orbx forum I removed all the shadows and VAS went down more than 50%. 

 

Hope that works for you same positive way worked for me.

 

Best

Juan.

saved some vas by setting cabin lights to manual and always OFF as part of my default panel state - David Lee

Pretty much I have similar configuration and software installed ,after read in Orbx forum I removed all the shadows and VAS went down more than 50%. 

 

Hope that works for you same positive way worked for me.

 

Best

Juan.

For the first time I completed a full flight, with Queen B 744, about two hours without this VAS leak and the cursed OOM's horn. I followed your instruction, also clean installation of the old nvidia driver 376.33. Thank s

I just experienced my first OOM in a while which occurred when landing at EGLL. it was probably to do with london scenery etc. I was only using the UK2000 VFR scenery EGLL as well so a little disappointing. She seems to work fine in most other places though so not to big of a deal.

I went back to P3d V3 for a bit just to see what all the commotion was about with regard to the 378.xx drivers. And sure enough for me, the 378.xx drivers cause an awful memory leak. Even the most recent hotfix driver causes P3dV3 to leak VAS like a sieve. It was impossible for me to complete 1 hour flights with the RealAir Turbine Duke without experiencing an OOM. And that was with cranking back IQ settings.

 

nVidia has bigger problems to contend with than worrying about FSX and P3d. The recent driver sets have been buggy even for video game users. Just check Guru3d.

For me the Queen uses 400mb more vas than the 777 I get an oom at the gate after every flight if I switch views. - David Lee

I went back to P3d V3 for a bit just to see what all the commotion was about with regard to the 378.xx drivers. And sure enough for me, the 378.xx drivers cause an awful memory leak. Even the most recent hotfix driver causes P3dV3 to leak VAS like a sieve. It was impossible for me to complete 1 hour flights with the RealAir Turbine Duke without experiencing an OOM. And that was with cranking back IQ settings.

 

nVidia has bigger problems to contend with than worrying about FSX and P3d. The recent driver sets have been buggy even for video game users. Just check Guru3d.

Ahh, that is why!!, I noticed as well,

ftx global, tutorial 747 flight, nothing else. and started with 3,4 vas and went up onto 3,7 then I thought this is impossibru...

 

Is there a way to revert back to older drivers?

Well, I have to say that, after initial issues with VAS and after few tests I am perfectly fine with what I see. True, FT scenery and for the same matter from other Vendors as well, cause initial high VAS, however, as it should be, goes down after take off and cruise. Things we know already. I completed over the weekend one 13 HR and one 7 HR flight and VAS both flight was anywhere between 2.4-2.7 GB....  (well in the green). No add on scenery, just usual, GSX, ASN. ORBX, HD APT, REX.....

 

It appeared to me that each and every flight is getting better (not sure if it makes any sense) but I tested before all of this and results were funny. Within 1/2 HR I started Queen on FT CYYZ (heaviest of all heavy add ons by FT admission) and VAS usage was 2.8...I let it idle...looked around etc....1/2 later I restarted my PC same thing again and VAS 3.1...?! I mean that's roughly 300 MB for same thing. Unless, FSX has a mind on its own I have no valid answer for all of this. Needles to say that same thing was/is happening with FSL as well. Only stability I have among all add-ons are NGX and 777, so go figure..

 

Specs: 6700, MSI1070, 32GB (high pollutant memory name that I can't remember), few SSD drives (with capacity to fill all available data from one State) and tons of other money wasting "high supposed" quality hardware pieces that work like placebo  in our mind so we can discuss on Forums...... :smile:

I have removed the orbx ftx global vector and orbx global no OOM at all, I believe the most problems causing the OOM is orbx global, even the short flight from EGKK to EGLL (UK2000 Scenery) I was getting a OOM.

Mo Dez