Jump to content

Sign in to follow this  
Petraeus

Version 2.1 OOM and possible memory leak.

Recommended Posts

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.


"It's too small, IT'S....TOO...SMALL"

Share this post


Link to post

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


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

Share this post


Link to post

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


Christopher Low

UK2000 Beta Tester

FSBetaTesters3.png

Share this post


Link to post

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.


Rick Abshier

 

 

Share this post


Link to post

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:

 

  • Upvote 1

Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post
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.

Share this post


Link to post

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:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

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.

Share this post


Link to post

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.


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

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.

 

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.

Share this post


Link to post

 

 


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


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

  • Upvote 2

Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

Share this post


Link to post

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.

Share this post


Link to post

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:


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556

Interests: Gauge Programming - 3d Modeling for Milviz

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,930.00 of $25,000.00 Donate Now
×
×
  • Create New...