Improved xml error reporting

[muemart]

If you made a level which needed to include some templates or used lua code, you probably noticed that the xml parsing errors, especially the line where the error supposedly was, were not very useful. I set out to correct that, and it turned out to be quite easy, because lua already provides a lot of information about the code. Here are some examples how the error looks now:

Picture of some examples (sorry for the shitty quality)

xmlerror.jpg (254.72 KiB) Viewed 26334 times

It works with lua scripts that generate xml content and normal xml files. The example on the left is an example of xml generated with a lua script, but it's not very useful either way because the script writes everything to the same line. The example on the right shows a "normal" xml error, not generated with a script, but the error is in an included file.
If even these messages are not enough to find the mistake (or if the message is wrong), the xml data that actually gets passed along to the parser gets saved to a file.

If someone's wondering how it works:
The level files etc. actually get interpreted as lua code. Everything that is not lua code ends up inside of a print() statement, and the <?lua ?> tags get removed, producing valid lua code. The print() function is redirected to a C++ function that appends the input to a string, which in the end is the xml data to be parsed.
With that you know which line from the final xml file gets printed by which print() call. You can get information on where (file and line) the lua print() call is from inside C++ code, and thus you know where each line from the final xml data originally comes from.

[x3n]

Wow, that's awesome!
I finally found time to test it a little. It works really well for included XML files.
(btw, yesterday I committed a small fix to make it compile with older settings (prior to c++11)).

Maybe we should tweak the whole error message a bit? The first message which contains the useless line number (e.g. "Line: 339" in your small screenshot) is better visible than the second message with the actual line number ("Line 15"). From my experience, people rarely ever read the whole message, so we should print the important information first.

[muemart]

Thanks for the fix. You can't disable language features in Visual Studio, so I have to rely on documentation to tell me if something is too new to use... which doesn't really work for syntax.

Yes, tweaking the error message is a good idea, but I don't have a clue how to make them better. Maybe just switch the order of report? The first one with the "wrong" line is from tinyxml, but I feel like we should keep it around, because I'm sure there are some edge cases where the tracing doesn't work (I already had a lot of problems with disappearing \n). You can then use the line from that message and look at the full xml dump to find the error there.
The whole output is very verbose, though...

[x3n]

Yes, maybe we could switch the order. And we could use "internal_error" instead of "user_error" for the tinyxml message. That makes it less 'important' and I think it will be printed in a darker shade of red in the console.

output levels -> http://www.orxonox.net/doxygen/namespac ... 6cf4e39a8d

[muemart]

I changed the message(s) accordingly. Sometimes the xml gets parsed without the lua stuff, and then the tinyxml message is usable (and the only one available), so the output level changes depending on that. I also made it so that there isn't an "Error [loader]" on every single line, which makes it a little bit more comfortable to look at. I guess this'll do, but if anyone has any bright ideas, by all means.

[x3n]

looks good to me. thumbs up!

Edit: I think this fixes ticket #333

[beni]

That is amazing. The fact that buggy levels can't properly be debuged was already a running gag, not this is all a thing of the past. I'm sure this will boost our level creation a lot and also help to properly implement automatic level creation tools for certain parts of our levels.

Great work.