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

[Guest]

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.

[vonmar 122]

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.

[Guest]

 

 

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

[NikkiA 7]

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.

[Brian Doney 127]

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.

[Guest]

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.

[spirit_66 2]

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

[fr92Furtif 0]

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.

[LHookins 3,103]

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

[vonmar 122]

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.
 

[Guest]

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...!!! ^_^ )

[n4gix 4,947]

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.

[mgh 89]

XML..."

[Main}

ContentErrorLogging=1

 

 

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

[spirit_66 2]

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

[charleslee201 19]

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