Sign in to follow this  
J van E

XML problems: which (add-on) planes are NOT affected?

Recommended Posts

I know there is a stickied compatibility list but with version 2.1 this has become rather useless because due to changes in the XML parser (or whatever you call that) a lot of planes are having problems with 2.1 and if they don't have problems, they at least may be causing OOMs. None of this seems to be taken into account in that list.

 

So I was wondering:

 

1. does anyone know if the default P3D planes are affected by this too? If so, which ones are affected and which ones aren't?

 

2. which addon (pay ware) planes do not have these xml problems at ALL?

 

3. which 3PD's are actively supporting 2.1 on this?

 

I might actually buy a (GA) plane right now if I know it will be 100% 2.1 compatible.

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

Jeroen,

 

"2. which addon (pay ware) planes do note have these xml problems at ALL?"

>> you meant "do not"  ...

 

Because LM P3D V2.1 is so new I have limited testing.

 

But, iFly737ND and Aerosoft's Twin Otter Extended for me are looking good.

 

Edit:

 

I think a new "list" for P3D compatibility is a good Idea.

 

Some developers are free upgrades .. some not.

 

Some developers have FSX products that still have problems running in FSX (need service pack e.g.) so their conversion to "native" P3Dv2.1 (fully functional/flyable) could be a good way off in the future ... where they were previously somewhat usable in P3D 1.4  e.g.

Share this post


Link to post

 

 


>> you meant "do not"  ...

 

Indeed. Edited, thanks.  ^_^

 

The problem with this problem is that planes that may look good, are causing havoc in the background (OOMs). You really have to know which planes do only use XML that is as 'clean' as LM wants it to be. I also heard that some planes don't use XML at all but I have no clue which ones those are or how you can know about that.

Share this post


Link to post

Good luck, but I wouldn't get too hopeful, the other thread has people reporting 'works fine' for aircraft where clearly some gauges don't work. I think most people just see if it loads and say 'close enough', and so we end up with a compatibility list that is near useless.

Share this post


Link to post

Indeed. Edited, thanks.  ^_^

 

The problem with this problem is that planes that may look good, are causing havoc in the background (OOMs). You really have to know which planes do only use XML that is as 'clean' as LM wants it to be. I also heard that some planes don't use XML at all but I have no clue which ones those are or how you can know about that.

 

I'd guess the very simplest rule of thumb would be to look at the gauges called in the panel.cfg, if the gauges themselves end in .gau or .dll they'd (hopefully) be fine, or at least not be subject to this issue.

 

If they are .cab or simply loose files with an .xml extension then who knows.

Share this post


Link to post

I'd guess the very simplest rule of thumb would be to look at the gauges called in the panel.cfg, if the gauges themselves end in .gau or .dll they'd (hopefully) be fine, or at least not be subject to this issue.

 

If they are .cab or simply loose files with an .xml extension then who knows.

 

Ok, well, that's a start.  ^_^ I will have a look at the various folders and also inside those cabs.

Share this post


Link to post

Isn't there an error logging in P3D v2.1 for such faulty things? I read somewhere, that these faults will be logged.

Spirit

 

PS: One has to add this statement in the cfg under [MAIN] section ObjectLoadErrors=1

Share this post


Link to post

I have no problems with Realair Legacy and Realair Duke v2 except the missing sounds (same issue in v2.0).

Officially these aircrafts are not supported for P3D v2.

 

I will check the gauge error log later.

Share this post


Link to post

XML in loose files or a CAB file will have errors caught during loading and will simply not work.  XML that's compiled into the mdl file doesn't seem to be checked and is probably what's causing the VAS leakage.

 

That's my understanding and it scares me.  Going back and applying new standards to legacy code, some of which can not be changed, is nasty indeed.  As I said in another thread, LM can't leave it like this and will likely be changing it.  Perhaps a "legacy" switch somewhere to use relaxed parsing.

 

Hook

Share this post


Link to post

Jeroen,


You mentioned: "I might actually buy a (GA) plane right now if I know it will be 100% 2.1 compatible."
I agree, I am with you on that. We need a new list with the 100% working aircraft in the list.

In fact, I may wait on a purchase until it has at least one Service Pack to repair the initial new aircraft release problems. If more serious problems are found after SP1 I may wait for two service packs and review the purchase possibility again.

I have noticed it has taken developers long as a year to iron out the real bugs (long lists of problems) with FSX aircraft because of staffing or multiple projects "in work" at the same time. As a result, the initial product releases get put on hold for months before fixes are finally released.

And, with P3D still ironing out its own problems, it could be a long time from now before we are seeing really functional "native" aircraft in P3D Version xx.
 

Share this post


Link to post

And, with P3D still ironing out its own problems, it could be a long time from now before we are seeing really functional "native" aircraft in P3D Version xx.

 

Indeed. We were all waiting for 2.1 so the various 3PD's could update their products, but what's the use of patching your product for a sim that's obviously needs yet another patch itself? If I was a 3PD I think I would wait with updating my addons until I was sure the core of the sim was set in stone. In that regard I fully understand that for instance Lionheart Creations has officially announced to not support 2.1 for now.

 

Of course it won't hurt to clean up the XML code (even if LM undoes this change the clean code will still work) but it remains to be seen how P3D evolves in the coming months: before you know it some core part of P3D will be changed (unannounced) and everyone will be in trouble once again.

 

It has been said before but the addons for FSX really went booming after SP2 had been released and it had become clear there would be no further development of the sim: that's what made FSX as good as it is! P3D will be in development for years to come and while that's absolutely great, this also means we probably have to be (far) more patient with updates for addons or P3D specific addons... It's a whole different ball game now. We have been spoiled with addons that sometimes were a real revolution in the FSX world but it's a totally different ball game now. Almost back to square one in some regards. P3D v2 isn't as backwards compatible as everyone (including LM) was thinking. (So they might as well start working on the 64 bit version today LOL In fact... if P3D v2 had been 64 bit, things would have been a lot more simple...!!! ^_^ )

Share this post


Link to post

Isn't there an error logging in P3D v2.1 for such faulty things? I read somewhere, that these faults will be logged.

Spirit

 

PS: One has to add this statement in the cfg under [MAIN] section ObjectLoadErrors=1

There is another error checking switch that is more applicable to XML "gauges" and "embedded model XML..."

[Main]
ContentErrorLogging=1

@Larry: Embedded XML in models is checked and validated by the parser. There were two really trivial errors in one of my models to which I was alerted: 50* instead of 50 *...

 

The "old parser" would look and that, shrug it's metaphorical shoulders and say, "obviously there needs to be a space there, so I'll just add one to be a nice guy."

 

Similarly, the "old parser" would auto-correct any number of "fat-finger" boo-boos in syntax. To be perfectly honest though, I'd far rather have this new parsing engine and the new diagnostic facility so I can be guaranteed that my XML script is 100% perfect.

 

The "old parser" simply encouraged sloppy practices. If it appeared to work properly, that was all the "validation" we had to go by.

Share this post


Link to post

XML..."

[Main}

ContentErrorLogging=1

 

 

People who live in glass houses... specially  with errors!

Share this post


Link to post

There is another error checking switch that is more applicable to XML "gauges" and "embedded model XML..."

[Main}
ContentErrorLogging=1

.........

Good to know, thanks for the information.

Spirit

Share this post


Link to post

Hi the 50*  sintax error  with you mention was on what model and the contenterrorlogging 1 sometime  very hard to interprete ; so for the average user,

Bill if you have the gns530 xml  corrected please give us more then a hint

Share this post


Link to post

As painful as it is, it's progress. And I like the idea of having add-ons available even if they don't work a 100%. Granted . I view this as a migration phase. The next phase IMHO is for developers to commit support for p3d. I think that will happen as LM continues to add those features that sets this apart and beyond fsx and users themselves commit.

 

One thing in Fsx favor, the fact that so many people have it even though it's development is practically dead, this is perfect for 3rd party developers that don't really care about advancing new standards. I am not sure if invoking 64bits is enough to attract this type of developer.

 

So for me, time will tell....but let me add this. The jump to 64bits would be more plausible with partnership. What's happening now is a prerequisite for that... I think.

Share this post


Link to post

There is another error checking switch that is more applicable to XML "gauges" and "embedded model XML..."

 

So... if I add both entries to my cfg I will at least be able to see which of my planes contain errors, right? Not that I will be able to do anything about it but I will at least be able to see which planes I can use without having to worry about error's and any effects those may have on my flying. That's a start.

 

EDIT

The errors will be logged in a file, I suppose...? Maybe everyone could post which aircraft do NOT give errors this way: if we all check our planes, we could compile a nice XML-okay-planes-list! ^_^

Share this post


Link to post

'If it works don't fix it'

That old XML parser is a center piece. Why change it knowing that third party add-ons orbit around it? Was this really the time to tighten XML when everybody is screaming lol

An analogy in the car industry is when freon was outlawed. Air conditioning components busted left and right because the replacement refrigerant was incompatible with the metals used (evaporators, condensers...)

....Amateurs

  • Upvote 1

Share this post


Link to post

EDIT

The errors will be logged in a file, I suppose...? Maybe everyone could post which aircraft do NOT give errors this way: if we all check our planes, we could compile a nice XML-okay-planes-list! ^_^

Yes, both "error logs" will be written to a folder found here:

x:\Users\YourUserName\Documents\Prepar3D v2 Files

  • ContentErrorLog.txt
  • ObjectLoadErrors.txt

Hi the 50* sintax error with you mention was on what model and the contenterrorlogging 1 sometime very hard to interprete ; so for the average user,

Bill if you have the gns530 xml corrected please give us more then a hint

That specific error (50*) was in the modeldef.xml script for the Milviz C310R. It is used as an animation scalar for a 3d modeled set of switches.

 

As for my custom GNS530, explaining the errors I made with my fat-fingers would not be particularly helpful to anyone, since it is highly unlikely that anyone else's script would have the same mistakes...

Share this post


Link to post

I'd love to have a strict syntax checker for my XML code.  It was always kind of hit and miss to write code that the only way you knew it was more or less correct was that it ran and did what you intended.  Just make it a separate program and don't mess with legacy code that cannot be changed.

 

Hook

Share this post


Link to post

Larry, here is a prime example of XML script that passes the only 'validation tests' previously available, which has been what is built into Visual Studio 2005, and using IE10/11 to "check for errors," but is utterly incorrect nonetheless:

<String>%((A:NAV1 STANDBY FREQUENCY), MHz)%!6.2f!</String>

The misplaced closing parenthesis "Y)," instead of "MHz))%" passes all validation tests since all they are checking for are missing items, ignoring completely misplaced items!

 

That is why I have decided to move all of my current and future development work to the P3Dv2.x test platform, even for FSX projects. After all, if I can "clean sheet" as 100% XML error free this can only be a positive outcome, eh? :Applause:

Share this post


Link to post

That is why I have decided to move all of my current and future development work to the P3Dv2.x test platform, even for FSX projects. After all, if I can "clean sheet" as 100% XML error free this can only be a positive outcome, eh?

Agreed!

 

Hook

Share this post


Link to post

I am happy to say the default Mooney Acclaim and Bonanza don't give any errors (presuming that loading them and turning everything on should be enough to test this). Those are the only default planes I am interested in.

 

The A2A C172 gave a bunch of errors but only reported missing files: no XML errors.

 

[error.0]

error=Gauge file not found: tester!tester
[error.1]
error=Gauge file not found: dbg!panel
[error.2]
error=Gauge file not found: A2A_C172!blackout
[error.3]
error=Gauge file not found: rxpGNS!GNS530
[error.4]
error=Gauge file not found: rxpGNS!GNS430
[error.5]
error=Gauge file not found: rxpGNS!GNS430
[error.6]
error=Gauge file not found: rxpGNS!GNS530
[error.7]
error=file "SOUND\null.wav" not found
[error.8]
error=file "SOUND\null.wav" not found
[error.9]
error=file "SOUND\null.wav" not found
[error.10]
error=file "SOUND\null.wav" not found
[error.11]
error=Gauge file not found: rxpGNS!GNS530
[error.12]
error=Gauge file not found: rxpGNS!GNS430

 

I presume those errors won't have any impact on OOMs or lead to leaks or whatever...? I suppose I could edit those missing parts out of the panel.cfg but I doubt if that has any benefit... Maybe it may even cause problems.

Share this post


Link to post

Missing "gauge files" won't cause any issues at all. They may even be commented out in the panel.cfg file, but are still being listed as "missing." Obviously, the rxpGNS.gau entries could be removed entirely, since RXP would not work even if it was present!

 

The null.wav file is probably an empty .wav file (a dummy as it were), although I have no idea why anyone would want to play a silent .wav file anyway!

Share this post


Link to post

I have no problems with Realair Legacy and Realair Duke v2 except the missing sounds (same issue in v2.0).

Officially these aircrafts are not supported for P3D v2.

 

I will check the gauge error log later.

My Lancair Legacy is flying swimmingly well (with all sounds when run in the legacy mode)with no noticeable problems other than what seems to be an overall problem with P3dv2.1 - a disparity between the GPS presentation and the gyrocompass.

 

Chaz

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