New installers shouldn't be touching the files at all but rather utilizing the built in support provided by L-M to incorporate entries into those files.

 

 

However, mostly these errors are handled elegantly in the software. It’s better to describe faults or incorrect actions within the software to the developer, rather than quote error logs in P3D.

 

If I didn't manually fix some "key" errors being reported in LM's ContentErrorLog I would not be able to use P3D and it would CTD frequently.  This is using 3rd party products "designed for" P3D V3 exclusively (with the exception of the Twin Otter, I have zero FSX products installed).

 

Like I said, I can fix most of them myself and there are ZERO repercussions from doing so ... remember these are all products flying the P3D V3 flag.

 

But as always ... the ball and the chain (FSX) ... my biggest concern is moving forward ... lets suppose there will be a 64bit P3D at some point in time, lets suppose the same practices still work in a 64bit P3D, do you think devs are going to change if they don't have to?  Maybe it would be prudent for LM to enforce the "new" way and provide no support for the "old way".  It's my understanding (from several sources) that most of the 3rd party revenue is coming from P3D installs.

 

I agree with Bill to some degree with the exception that newer installers aware of new P3D changes should use the new methods, not the old.

 

Cheers, Rob.

If I didn't manually fix some "key" errors being reported in LM's ContentErrorLog I would not be able to use P3D and it would CTD frequently.  This is using 3rd party products "designed for" P3D V3 exclusively (with the exception of the Twin Otter, I have zero FSX products installed).

 

Like I said, I can fix most of them myself and there are ZERO repercussions from doing so ... remember these are all products flying the P3D V3 flag.

Even so Rob, I doubt it would change their minds leaving alone or treading carefully to avoid causing problems, which is a bit different to requires show stopping fixes as you found. Hopefully it's not at all as bad for P3D as suggested in the grim situation you painted there. Hopefully the devs have sorted out those issues you found.

 

 

Hopefully it's not at all as bad for P3D as suggested in the grim situation you painted there.

 

I'm not holding the brush nor doing the painting, just an end user that is a software engineer with some P3D SDK knowledge.  I respond to those with the Brush and fix issues from/for the consumer end ... ignoring the ContentErrorLog is NOT something I would recommend.

 

It takes me about 15-20 mins to correct issues that come up and I repeat this step over time as I purchase more add-ons that generate errors.  The errors I'm able correct, I do correct, this has been going on for around two years or more.  I don't think it's a "grim situation", but I also don't understand why these issues can't be cleaned up?  If it only takes me about 15-20 mins, I can't see it being that much of a burden on those with the Brush.

 

The ContentErrorLog exists as a useful tool for both devs and end users, I don't see why it's being brushed under the rug as almost "hostile".  If devs disagree with the errors being report, then bring that up with LM.

 

Cheers, Rob.

Quite. But you wanted clarification as to why those devs appear to disregard the reports. I said they don't want to change anything if it's working OK. If you've found show stopping problems then that's to be taken up with your suppliers shurely?

Remember I said that "Developers should seek to eliminate all those error reports, since they are real." I'm not suggesting they be ignored.

There's plenty that are ignored because they amount to nothing as I think Bill was merely trying to suggest. The fact that you're handling show stopping errors Rob, isn't what we meant.

According to L-M not a single error in that list should be ignored as it impacts the core sim's performance.

According to L-M not a single error in that list should be ignored as it impacts the core sim's performance.

^^^ What Ed said. +1000

 

Furthermore, a developer (of any software) should seek and find all bugs, regardless if they cause performance issues or not. I know I do.

Yep, and that log writing to disk as well... I think Rob's talking about a few devs that recommended turning off the logs since they have a few inconsequential warnings in the log. But "brushed under the rug as almost "hostile" isn't what they are doing, and "If devs disagree with the errors being report" I haven't seen that in my travels, maybe Rob has.

...Regarding the location of dll.xml;
 

a location such as

"C:\Users\UserName\AppData\Roaming\Lockheed Martin\Prepar3D v3"

is presented depending on the user logged in

 

whereas

"C:\Users\All Users\Lockheed Martin\Prepar3D v3"

otherwise known as the physical location:

"C:\ProgramData\Lockheed Martin\Prepar3D v3"

is presented whatever User is logged in to the system.

 

So it can be seen that different configurations will emerge depending on the User that's logged in. Remember that P3D is a professional application and requires that it can be run in a secure system without Admin privileges.
 

Furthermore, a developer (of any software) should seek and find all bugs, regardless if they cause performance issues or not. I know I do.

Unfortunately, there are some errors reported that are so vague that they defy any attempt to locate them.

 

While I don't have an example to hand at this moment, several logs entries have mentioned a "blank space" as being the proximate cause of the error without any reference to a specific line or even surrounding text that can help pinpoint the precise "blank space" in question...

 

How does one search for a "blank space" anyway?

How does one search for a "blank space" anyway?

I know what you mean...

Been there, Try SQL, HTML5, etc. When an error message states at Line xx  near char yy. Whut?? there is nothing there!

In this case the P3D xml/code parser message is suboptimal (to say the least).

 

Occupational Hazards. (Sounds better in Spanish Gajes del Oficio)