Here is an example of a totally USELESS "error report" from the ContentErrorLog system:
Code:
[error.6]
error=Gauge: Non-gauge Error: Invalid script (command not found - perhaps a space is missing or there's an extra space?): ")"
Would anyone care to guess just how many instances there are in even the default modeldef.xml file where one will find a closing parenthesis followed by a blank space?
If you guess maybe 6,000 you will still be way too low...
Give us more 'clues' where this so-called error is located, please!
ContentErrorLog.txt
Yes, I already mentioned it here:
http://www.prepar3d.com/forum-5/?mingle ... pic&t=5816
Who designs a system that KNOWS in which file the error is but does not tell you?
And then the next question:
If the validator KNOWS there is a problem with the spaces, WHY does it not automatically fix it?
http://www.prepar3d.com/forum-5/?mingle ... pic&t=5816
Who designs a system that KNOWS in which file the error is but does not tell you?
And then the next question:
If the validator KNOWS there is a problem with the spaces, WHY does it not automatically fix it?
@minime, having read that post of yours, all but one of those errors do tell you specifically what file or gauge the problem exists.
a "non gauge" error means the problem is in the modeldef.xml file. All of your errors are specific to named Gauge: or the panel.cfg file.
One non-obvious error is "Adf1 signal". This is a deprecated token variable and must be replaced with (A:ADF SIGNAL:1, number)
a "non gauge" error means the problem is in the modeldef.xml file. All of your errors are specific to named Gauge: or the panel.cfg file.
One non-obvious error is "Adf1 signal". This is a deprecated token variable and must be replaced with (A:ADF SIGNAL:1, number)
Bill Leaming
Modeler and Programmer
Military Visualizations
Modeler and Programmer
Military Visualizations
-
- Lockheed Martin
- Posts: 341
- Joined: Thu Jan 12, 2012 7:05 pm
Well minime, that would probably be me. With the new content error reporting system, we wrapped existing internal (debug-only) text into the report. Internally to MS and LM developers there is sufficient information when coupled with the additional debug-only information. So no, we didn't clumsily design a cryptic useless system, but tried to leverage existing error reporting for external developers where there was none before. There are many of these reports and we try to fix them as they present themselves.
Quote:
Quote from N4GIX on March 11, 2014, 12:27
@minime, having read that post of yours, all but one of those errors do tell you specifically what file or gauge the problem exists.
a "non gauge" error means the problem is in the modeldef.xml file. All of your errors are specific to named Gauge: or the panel.cfg file.
One non-obvious error is "Adf1 signal". This is a deprecated token variable and must be replaced with (A:ADF SIGNAL:1, number)
Yes, I can probably find the filenames by searching. But I have like 100 aircraft on that computer so that will be a lot of searching and reloading aircraft.
I only pasted a couple of these errors, there are several hundreds of these lines in the file.
There just is no reason why I have to search for the filename if that debug functions already knows it.
So yes, I can fix those errors, but I will not do it now and just wait until the logger will actually give a specific filename. And when it does that I will probably write a script to auto-correct most mistakes, because it is just unrealistic for me to manually fix several hundred errors in unknown 3rd party gauges.
@minime: I thought you were talking about your own projects. No, I certainly would not expect you to find and fix other developer's errors! That would be foolish in the extreme.
Let developers fix their own work, or quit using them until they do.
One of the 'tricks' I'm currently using is to load a single project, then quit P3Dv2.1 entirely. I then prepend the name of the project to the ContentErrorLog.txt file for later use in debugging that project. For example: F86_ContentErrorLog.txt is now awaiting my attention for whenever I find the time to fix its problems...
Let developers fix their own work, or quit using them until they do.
One of the 'tricks' I'm currently using is to load a single project, then quit P3Dv2.1 entirely. I then prepend the name of the project to the ContentErrorLog.txt file for later use in debugging that project. For example: F86_ContentErrorLog.txt is now awaiting my attention for whenever I find the time to fix its problems...
Bill Leaming
Modeler and Programmer
Military Visualizations
Modeler and Programmer
Military Visualizations