Feature suggestion: detailed patchnotes

[zambol]

It would be good for ruleset creators and maintainers if updater would do a bit more detailed patchnotes log. At least to level "list of files changed".

Problem is this:
I updated my FGII Beta rulesets to 2.0.3.
Then comes 2.0.4. and i because i have no information as to wich files changed, i have to review all files for changes. And i will allways miss one or two.


-Zambol

[Shrp77]

Another nice feature would be a stack trace showing us where FG actually crashed (not the internal code, but the external code - i.e. our XML and LUA files).

I imagine a lot of FG crashes are due to improper formatting of the code files and some time may be the result of invalid combinations of commands...

I know it probably would take a lot of time to implement - and probably isn't high on the list of things to do, but it would help the ruleset coders a lot to get some measure of feedback regarding where they went wrong. (notice I use the royal interpretation of we, they etc... I actually mean me but I'm hoping I'm not alone in that ... :hurt: )

[sunbeam60]

How about using a good diffing tool, like Beyond Compare? (https://www.scootersoftware.com/)

[joshuha]

Another nice feature would be a stack trace showing us where FG actually crashed (not the internal code, but the external code - i.e. our XML and LUA files).

I imagine a lot of FG crashes are due to improper formatting of the code files and some time may be the result of invalid combinations of commands...

I know it probably would take a lot of time to implement - and probably isn't high on the list of things to do, but it would help the ruleset coders a lot to get some measure of feedback regarding where they went wrong. (notice I use the royal interpretation of we, they etc... I actually mean me but I'm hoping I'm not alone in that ... :hurt: )

Well you do get an error line with LUA scripts as far as errors are concerned in the console.

I think the XML is a bit more difficult because its not techinically process line by line. What I am assuming that happens is all the XML code gets compiled into one big node tree branching off from your base.xml file. If you improperly close out of a tag or something it doesn't know this until it has all the XML and thus may not be able to give you a good line number.

Not saying this couldn't be added and isn't a good request, it would probably just involved a little more tracking of things on their internal XML parser.

[Shrp77]

I think the XML is a bit more difficult because its not techinically process line by line. What I am assuming that happens is all the XML code gets compiled into one big node tree branching off from your base.xml file. If you improperly close out of a tag or something it doesn't know this until it has all the XML and thus may not be able to give you a good line number.

Not saying this couldn't be added and isn't a good request, it would probably just involved a little more tracking of things on their internal XML parser.

On some level they may be able to implement it in the reader itself; you would then be able to catch the parser exception in the reader which would give you the filename and depending on the reader implementation you would also get the exception (like: "Non terminated tag: <WindowClass> in myCustomWindow.xml").

When it comes to the internal mappings of the xml, I figure that the classes they map to would themselves be able to implement their own exception handling. It would be able to indicate what class has the problem (i.e. windowclass, windowframe etc.) even through the source (xml file) could be lost at this point.

Of course - implementing something like this would be quite the endeavor unless the base design structure supports it...

Here's hoping... :P