debugging can be a pain. not just that there is no documentation for the whole demigod code out there but also the error messages have meaningless linenumbers when you hooked a file and then there is an error in your code. so thats why i played around with luas debugging interface and wrote this script. this interface has its limitations so there is not always a function name available but there is almost always a sourcefile and a line! keep that in mind when you read the messages.
first thing it does it gives you another log function that can also print out tables. the function is called MODLOG
second thing is that everything that gets logged into the console (f9) is also being logged into a log file under /mods/Log.txt
third: its helps you with exception handling: you dont always need to write
local status, value = pcall(function....)
if status then
....
and so on. you just write your function and define it like this:
newfunctionname = SecureCall(oldfunctionname)
then when you call your function with newfunctionname() it is being logged when the function is being entered and finished. if there is an error it gets logged as well but with the correct linenumbers!
BUT THAT... only works, if you extract your dgdata.zip into the same folder as the zip and call it dgdata. so /demigod/dgdata.zip/ becomes /demigod/dgdata/
the script opens the original file, counts its lines and substracts it from the ones in the error message.
with this approach you also dont need to disable the logging, you just handle it like this:
if debug then
newfunctionname = SecureCall(oldfunctionname)
else
newfunctionname = oldfunctionname
end
so you can make the oldfunction local and change its name internally whenever you want. externally it stays the same
if this is "bad" in lua then just correct me and ill delete this tip
next thing the script does is that it gives you runtime information about the variables that are available in a function. it prints out their names and their values.
you just have to hook one function and use the function PrintInformation(1) of this script somewhere in the code. the 1 is for the stacklevel that you want to print out. 1 is the function from which printinformation is being called. higher numbers are for the functions below that. at the bottom of the script i defined SecurePrintInformation. you can use that as well but then there are 2 additional stacklevels so the 1 becomes a 3, 2 is 4 and so on. this is needless if you know where the stack begins else you get an error which is caught by the SecureCall function. this is just meant as an example!
this function prints out which function it examines actually (with file and linenumber and sometimes with name) and then a list of variables that are _defined_ in that function. so it doesnt print out the whole global stuff all the time.
i cannot guarantee that this is bugfree but ill update it if you find an error.
The Code
