Jump to content

Sign in to follow this  
Petraeus

Version 2.1 OOM and possible memory leak.

Recommended Posts

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.

 

I never experience OOM's in FSX or P3D 1.4 due to blurry, unloaded textures, though. This is new with P3D v2. The terrain engine seems to get out of sync with itself, constantly loading more data without getting a chance to unload old, no longer used data.

 

FSX/P3D 1.4 were never good and clearing old scenery data either. If you started from a complex departure airport, VAS usage would remain higher than if you started from a simple airport, even if you flew hundreds of miles away from your point of departure. However VAS usage is more predictable and doesn't spike in the middle of mostly empty, forested hills like I experience in P3D v2.


Asus Prime X370-Pro / Ryzen 7 1800X / 16 GB DDR4 3200 MHz / Asus GTX 1070 Turbo
Fractal Design XL R2 / Phanteks PH-TC14PE / Corsair CX650M
2 TB SSD / 4 TB HDD

Share this post


Link to post

 

 


FSX/P3D 1.4 were never good and clearing old scenery data either. If you started from a complex departure airport, VAS usage would remain higher than if you started from a simple airport, even if you flew hundreds of miles away from your point of departure. However VAS usage is more predictable and doesn't spike in the middle of mostly empty, forested hills like I experience in P3D v2.

 

Indeed, this describes a difference that is hard to explain only by looking at things like raw autogen/vegetation density.   I never had OOMs in P3D V2.0 and that is w/ as much as 5h flights in QW757, now it's lucky if I can do 1h+ in the same plane, same scenery, same slider settings.


Noel

System:  9900K@4.9Ghz@1.21v all cores w/ HT enabled, MSI MPG Z390M GAMING EDGE AC, Noctua NH-D15S, Corsair Vengeance 32Gb LPX 3200mHz DDR4, Sabrent NVme 2Tb x 2, RTX 2070 Super FE, Corsair RM 850W PSU, Win10 Pro, Dell curved 3440x1440, Saitek Yoke, TQ & Cessna Trim Wheel, UNLIMITED frames Vsync to 30Hz.

 

Share this post


Link to post

Please do not instigate such rumors.

 

I can personally assure everyone that Beau & company are fully aware of the problems extant with the 2.1 patch update.

 

What fails to register in my Snoopy head is why LM decided to introduce new restrictive XML parsing rules in a patch that was supposed to be fixing issues (HDR lighting, volumetric clouds...) and this without advising add-on developers ?!. Are the new parsing rules fixing any native P3D problem ?  If not, innovation mode was supposed to come later down the road in the development of a more comprehensive version. I'd love to hear the official LM explanation for this.

 

Also looks like a programmer knocked out the 'autogen paging' system that was working fine for fast airplanes in version 2.0... The 'Autogen Paging' system problem is a defective garbage collection task that loses trace of obsolete addresses piling up in the virtual address space (VAS).... Apparently a different garbage collection strategy kicks in when flying at low speed  :Whistle: ?! 

 

So if you want to fly an airbus in P3D (or any other large aircraft), turn off vegetation (the ultimate VAS assassin) and figure that you're going to lose about 1Gb of VAS per 700 miles due to non-vegetation objects that get lost in VAS.  For real long hauls I'd turn all autogen off... maybe leave a few clouds in a race against VAS depletion  :Black Eye:

 

.... growing pains it seems ;)

  • Upvote 1

Share this post


Link to post

 

 


.... growing pains it seems ;)

 

Does anyone really think that LM wont eventually negotiate through these problems and come out the other side? Its really just an exercise in patience on our part.... 

 

Just a slight setback..........  :lol: 

gkwt.jpg


Just Flight Beta Tester
 
We are all connected..... To each other, biologically...... To the Earth, chemically...... To the rest of the Universe atomically.
 
Devons rig
Intel Core i7 8700K @ 5.0GHz / 32.0GB G.SKILL TridentZ Series Dual-Channel Ram / ZOTAC GAMING GeForce® RTX 2080 Ti Triple Fan / Sound Blaster Z / Oculus Rift VR Headset / Klipsch® Promedia 2.1 Computer Speakers / ASUS ROG SWIFT PG279Q ‑ 27" IPS LED Monitor ‑ QHD / 2x Samsung SSD 850 EVO 500GB / 1x Samsung SSD 860 EVO 1000GB / 5 other regular hd's with up to 10 terabyte capacity each / Windows 10 Pro 64-bit / Gigabyte Z370 AORUS Gaming 5 Motherboard

Share this post


Link to post

What fails to register in my Snoopy head is why LM decided to introduce new restrictive XML parsing rules in a patch that was supposed to be fixing issues (HDR lighting, volumetric clouds...) and this without advising add-on developers ?!. Are the new parsing rules fixing any native P3D problem ?  

They aren't so much "new rules" as it is a case of eliminating the loose interpretation of those rules. As it happens, having fixed the reported "errors" in one of my projects, I've actually noted a small, but very noticeable increase in average framerates...

 

...in both P3Dv2.1 and FSX!

  • Upvote 1

Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

They aren't so much "new rules" as it is a case of eliminating the loose interpretation of those rules. As it happens, having fixed the reported "errors" in one of my projects, I've actually noted a small, but very noticeable increase in average framerates...

 

...in both P3Dv2.1 and FSX!

 

That makes sense, since the SIM doesn't waste time going through an error correction decision tree any more. Scrapping a quasi artificial intelligence module that allowed and processed a  loose interpretation of code should theoretically improve frame rates.

 

From now on its black or white, clean XML only... the XML either works or the non-compatible code massively piles up in a log (and uses up memory to eventually mess up gauges and stuff).

 

IMHO, the programming effort consisted of removing a post-processing function that gave failed XML code a second chance.

Share this post


Link to post

IMHO, the programming effort consisted of removing a post-processing function that gave failed XML code a second chance.

That is correct, up to a point at least. L-M has acknowledged however that their "error reporting log" does have some coding errors that are writing completely spurious entries, and that is consuming VAS... 

 

Further, some of the "error reports" are truly worthless, such as:

 

[error.0]
error=Gauge: FBS_GNS430_2d 
Error: Boolean does not evaluate to TRUE or FALSE

There are well over 300 such boolean expressions in that one gauge that should evaluate to either TRUE or FALSE...

 

...so which one of them is "faulty?" :Silly:  :Confused:   :LMAO:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

That is correct, up to a point at least. L-M has acknowledged however that their "error reporting log" does have some coding errors that are writing completely spurious entries, and that is consuming VAS... 

 

Further, some of the "error reports" are truly worthless, such as:

 

[error.0]
error=Gauge: FBS_GNS430_2d 
Error: Boolean does not evaluate to TRUE or FALSE

There are well over 300 such boolean expressions in that one gauge that should evaluate to either TRUE or FALSE...

 

...so which one of them is "faulty?" :Silly:  :Confused:   :LMAO:

 

 

This was processed by HAL9000 before LM fired him  :Big Grin:

ocr-b_hal9000_quote.jpg

 

Rest in peace HAL... (he was getting a bit schizoid though) LOL

 

Edited by FINXPAS

Share this post


Link to post
Guest

 

 


There are well over 300 such boolean expressions in that one gauge that should evaluate to either TRUE or FALSE...

 

At least you know it's something to do with a Boolean ... Microsoft's web services that I've coded report back to my client code things like "Not Found" ... that's it, nothing else, no inner exceptions, nada ... and guess what "Not Found" could mean just about anything from the web service actually not being found ... to I haven't increased the resource allocation (memory usage) for that web service (returning more data than it's default limit) ... to the value being passed to/from is not a member of the enumeration type ... and the list goes on ... debugging nightmare.

 

I hate web development, it's so cumbersome and fragile and has standards that no one follows (or more precisely everyone claims to follow 100% but is actually open to interpretation).  Please, send me back to the world of desktop applications ... all because of PCI compliance required by CC processors ... that frankly is NOT making "the web" any more secure.  Sorry, rant over...

Share this post


Link to post

Error: Boolean does not evaluate to TRUE or FALSE

Hm. Testing a float to be equal to zero?

 

What did the actual error finally turn out to be?

 

Hook


Larry Hookins

 

Oh! I have slipped the surly bonds of Earth
And danced the skies on laughter-silvered wings;

Share this post


Link to post

They aren't so much "new rules" as it is a case of eliminating the loose interpretation of those rules. As it happens, having fixed the reported "errors" in one of my projects, I've actually noted a small, but very noticeable increase in average framerates...

 

...in both P3Dv2.1 and FSX!

 

So in essence what you`re saying is this XML constriction could prove to be the most important update of them all. (after every XML error has been fixed in the content)


Sebastian

Share this post


Link to post

 

 


So in essence what you`re saying is this XML constriction could prove to be the most important update of them all. (after every XML error has been fixed in the content)

 

Basically, yes... for all new construction, and for existing aircraft that are still being maintained.  If I'm writing XML code, I'd prefer to have strict checking.  For some existing aircraft, the developer is no longer around or it's never going to be updated for whatever reason, and there's no way to fix any errors in XML code compiled into the model files.

 

Hook


Larry Hookins

 

Oh! I have slipped the surly bonds of Earth
And danced the skies on laughter-silvered wings;

Share this post


Link to post

Hm. Testing a float to be equal to zero?

 

What did the actual error finally turn out to be?

 

Hook

I've no idea since I still haven't found it! Wes Bard did suggest this to me though:

 

As far as your error below:

error=Gauge: FBS_GNS430_2d  Error: Boolean does not evaluate to TRUE or FALSE

 

This error occurs when the value being evaluated in the script is not one of the following strings: "Yes", "True", "1", "Y", "Ok" or "No", "False", "0", "N", "Cancel"

 

The which is reasonable, but unhelpful in the end because even this is a boolean expression, which requires absolutely none of the above:

<Code>(A:FUEL CROSS FEED,bool)</Code>

The boolean return is implicit in the script. The contents of <Code>...</Code> will evaluate to either "1" or "0"...

<Code>(A:FUEL CROSS FEED,bool) 1 ==</Code>

The above is the explicit version, which while perhaps more clear to the human eye is superfluous.


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

Ah, found your problem!  FUEL CROSS FEED is not a bool, it's an enum, 0 or 1.  Apparently that couldn't be converted to a bool by explicitly specifying it with ",bool)" and that's what threw the error.

 

Hook


Larry Hookins

 

Oh! I have slipped the surly bonds of Earth
And danced the skies on laughter-silvered wings;

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    31%
    $7,940.00 of $25,000.00 Donate Now
×
×
  • Create New...