.....

The majority of the errors reported by the 'tool' are of the syntax variety and have no operating effect on the gauge. .....

There are not only errors in gauges, one can see a lot of other errors too. Anyway, an add-on with a lot of errors will become a bad reputation for me. Especially if it wont be fixed soon.

Spirit

 

PS: I developed software for nearly 4 decades and I'm retired now but nobody need to tell me about errors and how to avoid them. I have only this comment for lazy coding - it's "quick and dirty".

There are not only errors in gauges, one can see a lot of other errors too. Anyway, an add-on with a lot of errors will become a bad reputation for me. Especially if it wont be fixed soon.

SPirit - I am not really disagreeing with you - my point is - *IF* the gauge (or whatever) was working just fine and you didn't know about the errors you wouldn't care. So it's not the actual errors that are the problem it's the fact that YOU KNOW they are there that bothers you.

 

I am NOT talking about errors that have any effect - those certainly need to be fixed but give me a break please - to complain because some program flags an extra space as an error???

 

Maybe all the developers should go through and make their stuff compatible with the error diagnostic and charge everyone extra for the update.

 

I also have been a programmer for decades and have seen errors flagged in the COMMENT sections of code that have absolutely NO working code but the program is flawless. I think this type of error can create a false impression about the "program".

 

Vic

SPirit - I am not really disagreeing with you - my point is - *IF* the gauge (or whatever) was working just fine and you didn't know about the errors you wouldn't care. So it's not the actual errors that are the problem it's the fact that YOU KNOW they are there that bothers you.

 

If you knew that there was an error somewhere, wouldn't you want it to be fixed? Of course you wouldn't care for the error if you weren't aware of its existence.

 

I totally didn't say that those errors are the culprit of OOMs in Prepar3D 2.1 (we all know by now that it's the trees causing the biggest problem), but Wes Bard himself said that those errors contribute to VAS usage and performance issues, and you really can't deny that Carenado gauges are really bad on performance. That alone confirms that the gauge is either not working right or is poorly optimised.

 

Besides, what about the remaining graphic glitches like the landing lights not illuminating the ground and window reflections missing? What about the Prepar3D 2.0-compliant installers Carenado promised about but never added? Do you still think that Carenado don't have to release patches for their existing aircraft?

BOY! Talk about a failure to communicate!

 

Of course I'd want all errors fixed. I never said they shouldn't and I said nothing about graphics, OOMs or anything else.

 

My whole point was about logging the errors PERIOD. For most users, IMHO, this is a bad idea and leads to the exact type of noise we are seeing in this thread. We have users of varying degrees of experience - a great many will understand the errors and either fix them themselves or nag the developer to do same ( an idea which I support!) but I believe there are a GREATER NUMBER (my belief so please don't ask for documentation) who do NOT understand the situation and will create endless panic threads about the "errors" thereby causing a bunch of possibly needless commotion.

 

That's my point - you can have the last word - I cannot think of any other way to explain my point.

 

Vic

Guys!
 
1. The ContentErrorLog system itself is flawed somewhat in that it is flagging non-errors as errors. Wes Bard, et alia at Lockheed-Martin have admitted this, and are fixing them as fast as I and a few others are documenting and reporting them!
 
2. Those "errors" being flagged in so-called comments are in fact because the comments themselves are not really proper comments! By this I mean that a double-slash "//..." that is used in .cfg files for 'commented stuff' is not valid or licit in XML scripts. There two recognized 'comment tags' valid and licit in XML:

<!--  insert comments here -->
(* insert comments here *)

3. Another example of false "error" flagging is occurring with some .fx files, where the first [Library Effect] section is not being recognized as a valid section head, which generates a cascading list of false "error reports" being generated.

 

In summary then, until such false reporting is tracked down and fixed, the ContentErrorLog.txt report itself is only of value as an aid to finding and fixing legitimate errors, and should not be taken as an indication that any given product is fubared... :wacko: