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.

 

 

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.

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

Rob,

 

maybe you should wait a bit as Wes Bard made a statement today that they are working at a Hotfic for your problems which are ours as well.

 

just have read here

 

http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=5696

 

 

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

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!

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.

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:

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:

 

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

 

Edited February 25, 201412 yr by FINXPAS

 

 

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

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

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)

 

 

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

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.

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