I found the ContentErrorLog file to have been extremely useful in correcting coding errors in xml-based panel gauges. When I first opened the log file, there were 999 error messages (some were repeated). Now, there about 13 left. By commenting out various gauges in the panel.cfg file, I was able to determine which gauge was causing these error reports. However, I was not able to fix them.

 

Nine of these errors were located within a gauge with over 30,000 lines of code, a Garmin MFD.  The error messages looked like this:

 

      [error.1]

      error=Invalid variable (missing : - did you forget a macro?):

      [error.2]

      error=Invalid variable (missing : - did you forget a macro?): 0

 

How on earth is one to locate an inappropriate " " or "0" in 30K lines of code? What is missing in the error message are a) the name of the gauge file the error was found in, and b) the line number of the actual error. Surely, the xml parser knows this info? If one had this info, fixing the errors would probably be straightforward. As it is, I have no hope of correcting the remaining errors.

 

On a very positive note, before fixing the other errors, I was getting OOM's after about 30 minutes of flight. Afterwards, I have not encountered any OOM's, even after several flights of about 150 minutes; I will try longer flights soon. VAS depletion has mostly been eliminated. It is definitely worth fixing gauge errors, not to mention that fixed gauges actually work better! Thank you LM for this brilliant tool, although it could stand some improvement.

 

Frans Kes

 

 

Great feedback Frans, looks like this wasn't the end of the world after all, who would have thought! Looking forward to whatever changes are coming, both from LM and TPDs.

 

Sent from my Mobile thing

I don't know... I heard about XML 15 years ago thought it was interesting in terms of classifying things , but 30 thousand lines of code to describe the operation of the gauge is pretty ludicrously inefficient... And I understand there is a similar verbosity of code involved in the flightplan file for PMDG's 777.

 

Isn't there a better way?

 

I think it could be done in C++with arrays, in Less than a thousand lines, just sayin...and I'd love to hear coder's responses to that... I love learning new stuff., And I ain't too proud to be shown to be wrong...

 

Wishing all great day and waiting for responses with baited breath,

 

Chas

I am not the original coder. I purchased the license for the Garmin 1000 package (PFD, MFD, Audio, and AP) from Don Kuhn (fs2x.com). It worked in FSX, but when I ported it to P3D1, the MFD always caused P3D to crash. Without the ErrorContentLog file, it took me a full year to find the root cause of the crashes and fix it, even with help from Mr. Kuhn; because of the crashes, I was unable to see what worked and what didn't. [Clearly, LM's xml parser had already changed from FSX.] Believe me when I say that 30K lines of code is not excessive for the MFD, which provides much more Garmin functionality then MS's version. I further created versions of the PFD and MFD gauges to work for 15 aircraft (turboprop and piston). The 30K lines of code are not commented.

 

Mr. Kuhn's fs2x website has an operation manual for the gauges.

 

I don't know if the ErrorContentLog tool would have worked when the gauge caused P3D to CTD.

 

Frans Kes

It can already be done in C++, and has been done,

Who makes it? And what aircraft does it support? Because it is compiled means that I cannot add new aircraft models.

 

The G1000 I love to use is modelled for the Baron 58; King Air 350; Cessna Grand Caravan and 172; De Havilland Beaver, Dash-8, Sea Otter, and Twin Otter; Maule Orion; Mooney Acclaim and Bravo; Pilatus PC-12; and Piper Malibu Meridian.

 

Frans Kes

Frans, as far as I'm concerned, the new ContentErrorReport.txt log has been a wonderful development.
 
I've been in email correspondence with Wes Bard, and have tested out the revised .dll package (patch forthcoming). I validated their concern that what the new system 'broke' in terms of back-compatibility has now been fixed. IOW, third-party custom gps units will now work...
 
...well, at least they will work as well as they did pre-v2.1 patch. After all, mal-formed syntax is still a bad thing, but these syntax errors no longer will prevent what did work previously from working, even if not quite correctly! 
 
I've also had some dialog with him regarding the opacity of the reports. Some of them are -as you've noted- essentially meaningless. I have my own examples of that as well!
 
I've not seen any errors such as the one you used as an example. All of mine are listing either a specific "gauge" or in the case of embedded scripts, a "non-gauge" entry, such as:

[error.0]
error=Gauge: Non-gauge Error: Invalid script (command not found - perhaps a space is missing or there's an extra space?): ">"
 
[error.1]
error=Gauge: Non-gauge Error: Invalid script (command not found - perhaps a space is missing or there's an extra space?): "els"
 
[error.2]
error=Gauge: Non-gauge Error: Invalid script (command not found - perhaps a space is missing or there's an extra space?): "{"

Somehow what I'd added after this got "lost..." Perhaps I wrote too much?

In any event "error.0" will be difficult to find in the modeldef.xml for this specific aircraft.

The next two "errors" however are evidently generated by an extra space between the "els" and the trailing "{", so a search for "els {" should quickly locate that one!

Edited February 26, 201412 yr by n4gix
corrected "not" to "now", corrected OP's name!

I've had those errors to fix as well; I'm assuming that the descriptive "Gauge" is the name of the gauge file with the errors?  The message type I presented probably came from a different area of the parser. Nevertheless, a line number would be nice.

 

Frans Kes

I've had those errors to fix as well; I'm assuming that the descriptive "Gauge" is the name of the gauge file with the errors?  The message type I presented probably came from a different area of the parser. Nevertheless, a line number would be nice.

 

Frans Kes

Frans, here is an example where the precise gauge is named:

 

[error.22]
error=Gauge: FBS_GNS430_2  Error: Boolean does not evaluate to TRUE or FALSE

Yep, I've had those, too. Don't forget, I started out with 999 errors, of all types. The ones I mentioned are the remainder because the error message was so obtuse. A couple of more leftovers dealt with a freeby Ottawa airport that referenced missing texture files; again, the name of the airport was not provided:

 

    [error.10]

    error=Texture OVERDOOLIGHT.DDS failed to load (FE_REQUEST_STATUS==13)

 

The reasons I know what airport it referred to were a) the CYOW airport was the only add-on with texture files and b) the file names were close to ones that existed.

 

Frans

Frankly I've strongly suggested to Wes and company that they limit the error log to one entry per error.

 

One project I "sanitized" last week started out with 537 listed "errors." The hardest job for me was to first "rationalize" the error .txt file to remove the duplicated entries!

 

Once I'd done that, I wound up with a mere 38 "unique" errors to deal with. The first time one looks at a typical ContentErrorLog.txt file could possibly trigger a heart attack, as the long, L O N G list of supposed "errors" is truly frightening, not to mention disheartening!!!  :LMAO:

Luckily, as I started resolving the issues numerical order, the many repeats quickly disappeared.

 

Frans

Believe me when I say that 30K lines of code is not excessive for the MFD, which provides much more Garmin functionality then MS's version.

Frans Kes

And how many of those 30 K lines were XML?

 

Regards,

 

Chaz

It can already be done in C++, and has been done,

at what efficiency vs XML do you think? Could you give an example for an instrument as complex as the G-500/1000?

 

Regards,

Chas(Siri thinks my name is Chaz)

All 30K lines were xml - no comments, except for a couple of dozen at the top.

 

 

BTW , it's  a bit unfair to compare the compiled C++ to xml. After all, the C++ source code is probably just as large (maybe even larger) as xml. However, the xml language is rather complex compared to C++, and therefore is more difficult to debug. And since xml is interpreted, it is much more CPU-intensive. I agree wholeheartedly that compiled C++ would be much better than xml, but then I wouldn't been able to modify it the G1000 code.

 

Frans