search

RPTools / maptool

Virtual Tabletop for playing roleplaying games with remote players or face to face.
http://rptools.net
GNU Affero General Public License v3.0
790 stars 257 forks source link

Simplistic Built-in Debugger/Code Trace #797

Open aliasmask opened 5 years ago

aliasmask commented 5 years ago

I thought about doing this with the macroscript using the new log.setLevel() macro but there are some things needed that don't exist yet in the macro code. One thing that can't be done is import the maptool.log file showing the current debug info and changing some of the preferences so that it doesn't interfere with the debugging process, namely the show statsheet on mouseover. The statsheet will run code on mouseover which may add unneeded info in the debug trace. Another thing not able to be shown in the debugging info is the current macro being run.

What I would like is a Debug Button that turns it on and off. It's basically just a code trace showing the macro and lines of code being executed up to the point of the error. Showing the macro name either as a header or in each line would be very useful in the trace. Turning the debugging on would turn off the Show statsheet on mouseover and turn on the Use shift to show statsheet Preferences. A popup will show debugging info if an error occurs or if execution is ended early with an abort or assert, but not otherwise. The popup will only show X number of lines and have an option to open the maptool.log file from the popup for full debugging information.

Turning off the Debug Button will restore the original Preference Settings and no longer show a pop-up on error or abort.

For bonus points, there could be a link on the error that will change the map and center to token with the error and open the editor to specified line of code.

I think this could be expanded upon, but for me this will solve 99% of my debugging needs just knowing where the error occurred.

JamzTheMan commented 5 years ago

There is a lot to digest here... Some things easier than others...

Not sure we know the line number of the macro today, maybe that's a parser 2.0 thing?

aliasmask commented 5 years ago

Wouldn't need a line number, but knowing the token and macro it came from is most important.

aliasmask commented 5 years ago

Basically, it involves adding a button to the panel, accessing the maptool.log file and displaying the last 20 lines of the MapToolLineParser. MapToolLineParser would need to include the token name and macro or include it in the debug info some other way.

Azhrei commented 5 years ago

Adding a line to the log when a macro is executed and detailing the macro name and token details (which token the macro is on, which token is the “current token”, and maybe other info) should be easy.

Line numbers can’t currently be done because of the way the parser works (it doesn’t pay attention to line breaks, so no line numbers exist and retrofitting would be quite difficult; I remember looking at this many years ago!). This is likely a parser 2.0 feature.