Version 2.1 OOM and possible memory leak.

[NikkiA 7]

I doubt LM can leave the parser in its current condition.  "Oh, all you have to do is go back and clean up all your code..."  EXCUSE ME!?  Some of these guys are no longer alive.

 

People assumed that Auran would cave when they did the same with Trainz assets, 'just fix up the [what are now] errors, and it'll all be golden', it was ~3 years of long pain while they refused to back down on the strictness of the new parsing, and they still refused in the end, they just conceded defeat by allowing the community to modify content that had been written by others on the download station.

 

LM doesn't have the benefit of a partial copyright transfer as with the trainz download station, and thus if LM digs its heels in, all we can hope for is that others come along and replace the aircraft that have been rendered 'obsolete' by the new XML parser.

 

I hope that you're right, that LM realise they can't dig their heels on this, but if not, it's going to be painful, and it may even be enough to kill P3D as the 'progress from FSX' path.

[LHookins 3,102]

It looks like from some of the statements from LM that the OOMs are caused by errors being continuously thrown from compiled XML in mdl files.  That's fixable.  What's not fixable is getting the gauges to work with the current strict interpreting.

 

Too bad about Auran.  I'm sure LM realizes this breaks backward compatibility, one of the major selling points of P3D, at least to the flight sim community. 

 

Heck, if they leave it the way it is, they might as well go to 64 bits right now.  If you're going to break backward compatibility, you might as well go whole hog and do it right, and break everything.  No halfway measures!  Damn the torpedoes, full speed ahead!  I'm sure many in the community would agree.

 

Hook

[Guest]

As I posted in another topic: instead of changing this XML business, LM might as well have said "Screw backwards compatibility, let's go for 64 bit right away".  ^_^ You would say that for a sim like this the planes are the most important, not the scenery, and now they are breaking the planes while afaik 64 bit would mainly hurt scenery (correct me if I am wrong). Anyway, it's very strange that they changed this so easily without apparently thinking of the consequences. And without informing/consulting 3PD's.

[Christopher Low 5,331]

At this moment in time, reinstalling FSX instead of "upgrading" to P3D seems like the best decision I ever made.

[ricka47 611]

At this moment in time, reinstalling FSX instead of "upgrading" to P3D seems like the best decision I ever made.

 

I may indeed be re-installing FSX again soon as well.  This is unfortunate though.

[n4gix 4,947]

900 issues in a GPS?  Somehow, I believe it.

Since I'm the guy Bill Ortis (Lionheart) referred to, let me issue some clarification on this report.

 

First of all, what I shared in the FS Developer forum was just from a quick glance at the ContentErrorLog.txt for the Milviz C310R, but that number of "errors" included all XML "gauges" as well as embedded XML in the model, and various .cfg file entries.

 

On closer examination however, I discovered that many of the same errors were repeated in the log ten or more times. Furthermore, once I started "fixing" the errors in the report (after having commented out all but one "gauge" at a time), I found that quite a few (actually most of 'em) were what I'll term "cascading errors," meaning that once I'd fixed the real error, a dozen or so immediately following in the report were also now "fixed." The conclusion of course is that once the "trigger error" was fixed, all subsequent errors that depended on the "trigger error" were now cleared as well!

 

The condensed version of the above is that in my GNS530 there were really only six minor syntax errors, even though the raw report had nearly one hundred listed!

 

Quite frankly the hardest challenge for the developer lies in interpreting the error log itself, since all @macros are "expanded" in the report, which makes searching for the relevant portion of the raw XML script more than a bit difficult.

 

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! :yahoo:

 

[Guest]

Thanks for the interesting information, Bill! It's nice to get a peek behind the scenes like this. And good to hear the amount of errors isn't as big as it seemed to be. "Obtuse as hell" doesn't sound too good though, but I am sure (?) that in time all developers will know how to 'read' that log, specially if you keep in touch with each other.

[n4gix 4,947]

Jeroen, I just posted pretty much the same information at FS Developer as a way of trying to help other developers get up to speed.

 

However, I won't bother posting this on the Prepar3D forums simply because it'd just get "lost in the noise" there...

 

...I do however send a detailed report to L-M directly. :ph34r:

[ChaoticBeauty 6,692]

I'm starting to wonder whether Beau is talking crap or not. He said that "they've improved the memory management system, but because of the new effects, memory usage will be higher". Well, even with all the GPU effects turned off, Prepar3D 2.1 is still much worse in memory management in FSX! And I wonder how that can be, since DX11 massively reduces CPU overhead over DX9 (even DX10 mode in FSX is said to eliminate OOMs). And it's a fact that 2.1 is more problematic in this area compared to 2.0. They can't blame the aircraft's speed when obviously 2.0 had less of that problem.

 

As for the parser, since it breaks full compatibility with a huge number of add-on aircraft (is it true that some defaults are broken too?) and aircraft will have to be recompiled with fixes for the gauges, would there be a difference if Prepar3D 2.1 was 64-bit? Not at all. I honestly wonder why they didn't follow that path since they seem content to have add-on developers patch their aircraft to work with 2.1.

 

And they still haven't started the changelog for Prepar3D 2.2. Gives me the impression that they think 2.1 is perfect, and it's up to add-on developers to ensure their add-ons are fully compatible. They really need to realise that the platform is broken.

[n4gix 4,947]

And they still haven't started the changelog for Prepar3D 2.2. Gives me the impression that they think 2.1 is perfect, and it's up to add-on developers to ensure their add-ons are fully compatible. They really need to realise that the platform is broken.

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.

[ChaoticBeauty 6,692]

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.

 

But they just don't seem aware that Prepar3D 2.1 is completely broken! Since 2.1 is obviously worse when it comes to memory management, why do they blame it on "aircraft speeds that cause bad autogen paging" when this was something that didn't matter with 2.0 or 1.4 or FSX? Why don't they just say "we are aware that 2.1 is having more memory problems compared to 2.0 and we'll try to fix them" instead of introducing "issues" that didn't exist before?

 

And their excuse for not reverting the XML parser is just horrible. They're fully aware that the new parser has broken tons of aircraft that will never be updated because either they were free or the developer is dead, yet they're still refusing to revert it. From what I understand, they didn't move to 64-bit yet to maintain compatibility with as many add-ons as possible, yet they're breaking so many aircraft over a silly reason?

 

Giving them one last chance with Prepar3D 2.2. If they don't wake up and realise that lots of things have to change, Prepar3D will remain in that state forever.

[LHookins 3,102]

 

 

On closer examination however, I discovered that many of the same errors were repeated in the log ten or more times.

 

We've sure seen this one a few times.  Misplace a period in a COBOL program and see what kind of errors you get.    I wasn't meaning to imply that there was a problem with the gauge, or especially with the gauge programmer, but that the GPS gauge code is incredibly complex anyway.  I've been able to make minor changes, but for the most part I just throw up my hands.

 

 

 

"cascading errors," meaning that once I'd fixed the real error, a dozen or so immediately following in the report were also now "fixed."

 

Yup.  Seen that one a few times too.  It's more common to fix one error only to have several more uncovered.

 

 

 

yet they're still refusing to revert it.

 

I haven't seen a flat refusal to revert.  You have a link?  I any case, I don't they have a choice.

 

Did anyone else read Fr. Bill's original post about the XML parser changes and have their stomach tighten up before the end of the sentence?  I already knew what kinds of problems it would cause, and the implications.

 

I desperately want P3D to succeed, and the current state of the program doesn't seem to point in that direction.  I believe they will fix the problems.

 

Hook

[n4gix 4,947]

They will be looking closer at the XML parser to see what might be done to mitigate the current issues. Please understand that their forums are not their primary means of communication with developers...

[ChaoticBeauty 6,692]

I haven't seen a flat refusal to revert.  You have a link?  I any case, I don't they have a choice.

 

Did anyone else read Fr. Bill's original post about the XML parser changes and have their stomach tighten up before the end of the sentence?  I already knew what kinds of problems it would cause, and the implications.

 

I desperately want P3D to succeed, and the current state of the program doesn't seem to point in that direction.  I believe they will fix the problems.

 

 

There may have been one or two new checks added as well, but we haven't gone through it with a fine tooth comb just yet. If the xml validates, but some scripts have errors, the system can get in a state where the same error string is created and logged over and over again eventually leading to OOMs. 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. We're sorry about the legacy content effected by this. A silver lining may be that add-on developers might be motivated to go back and clean up script errors

 

Beau Hollis

Rendering System Lead - Prepar3D® Team

 

It's not a flat refusal just like you said, but Beau is making himself perfectly clear in that reply. They're apologising for breaking legacy content and recommend that developers go back to change their aircraft. Because they're not reverting to the old XML parser engine.

 

I really want Prepar3D to succeed too because it's high time we had a replacement for FSX, but what Lockheed Martin are saying about the obvious problems Prepar3D has is just beyond frustrating.

[n4gix 4,947]

We've sure seen this one a few times.  Misplace a period in a COBOL program and see what kind of errors you get. 

I cut my programming teeth using COBOL, Fortran, and RPG all in the same semester back in the dark ages. I had the same professor for all three languages. He got a bit miffed at me once for turning in an assignment using RPG for the I/O, COBOL for data storage, and Fortran subroutines for the math... :lol:

 

With regards to "leaking" the only evidence I saw of that was a result of the two minor errors in the model's embedded XML script: those two instances of a missing space "50*" instead of "50 *". Those were being written to the error log around 18Hz, and very quickly wrote thousands of lines to the error log!

 

Errors in the XML "gauges" however were not "leaking" however... :ph34r: