Moderators Popular Post IIYAMA Posted May 17, 2017 Moderators Popular Post Share Posted May 17, 2017 (edited) Debugging Do you know what debugging is? You might think you do, but unfortunately (in my opinion) only ~15% of the scripters in the community do know the full definition of it. Many people think that debugging code is the same as looking in to the Debug Console and waiting for warning + errors to show up. That's indeed debugging and yet it never provide all information you need to build your scripts. It only can say what goes wrong at a certain line. With other words, the Debug Console by default will only show a limited amount of mistakes you have made in your code. So what is next? You fixed all warnings and errors and yet it doesn't work. You start with making your code visible! I guess 70% would think: Making code visible? Ehhh how??? Let me write it down a little bit different: By using Debug Information making the behaviour of the code visible. I guess 50% would think: Eh what? behaviour of code????? Let me give you an example. Example: (1) outputDebugString("the script has started") -- < this is a debug line if true then outputDebugString("code works here") -- < this is a debug line else outputDebugString("code shouldn't be working here") -- < this is a debug line end Debug console "the script has started" "code works here" The debug console is NOT information for players, it is information for YOU developers! BTW this is a debug line outputDebugString("test") -- < this is a debug line In this case it is just a piece of code that shows information in the debug console. Example: (2) local playerName1 = "snake1" local playerName2 = "cow" if playerName1 == playerName2 then outputDebugString("players playerName1 and playerName2 do share the same name. Name: " .. tostring(playerName1)) -- < this is a debug line else outputDebugString("players playerName1 and playerName2 do NOT share the same name. playerName1: " .. tostring(playerName1) .. ", playerName2: " .. tostring(playerName2)) -- < this is a debug line end Debug console "players playerName1 and playerName2 do NOT share the same name. playerName1: snake1, playerName2: cow" Easy isn't? The concept behind this debug method is to see what the code does / doesn't execute. Is this method handy? It is actually the very basic of debugging, for code that doesn't contain any errors/warnings. I would say it is handy and it is a very powerful method too. It is also handy for people who do not know how to script. If you want people to help you with your code, but you do not know what is wrong with it. You can add those debug lines and point out to where the code stops working. This will make it more efficient for you and the scripter to work out the problem, because the scripter knows where to look. How much debug lines do you have to add to your script? 1? 10? 100? 1000? You could start with around 100 debug lines and as you learn how to script, you can reduce it to 10+ debug lines. Too much debug lines are not always good, because they will give you too much information and it will cost time to manually filter them. So I recommend you to remove some of them afterwards. When you are finished with the tested code, you can remove 90+% of them. Feel free to disable them instead of removing them, if you know that you are going to need them again. For complex code, I use around 25 debug lines, SO DON'T HOLD BACK! Render events It is strongly recommended to remove debug lines that are executed on onClientRender/render events when you are finished with your code. Because that can have influence on the smooth fps.(It will not drop much of the fps, but it can make it feel unsmooth) Clearing the debug console? /cleardebug Know your tools: outputDebugString -- Show a message on the Debug Console bool outputDebugString ( string text, [ int level=3, int red=255, int green=255, int blue=255 ] ) --- outputConsole -- Show a message on the F8 panel. bool outputConsole ( string text ) -- client bool outputConsole ( string text, [ element visibleTo=getRootElement() ] ) -- server --- inspect -- Convert one mixed value to a string. string inspect ( mixed var ) --- print -- Show a message on the terminal / serverwindow / Debug Console. bool print ( string var1[, string var2, string var3...] ) --- tostring() -- Convert a value in to a string. (but for objects/elements, inspect works better) --- iprint -- Show a message on the terminal / serverwindow / Debug Console (convert multiple mixed values automatic to string, no need for tostring or inspect) bool iprint ( mixed var1[, mixed var2, mixed var3...] ) --- outputChatBox -- You can also debug with outputChatBox (even though it is less efficient) bool outputChatBox ( string text [, int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- client bool outputChatBox ( string text [, element visibleTo=getRootElement(), int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- server Debug message levels 0: Custom message 1: Error message 2: Warning message 3: Information message (default) Addition by @Hale https://wiki.multitheftauto.com/wiki/OutputDebugString Advanced tools: local line = debug.getinfo(1).currentline -- get the line of the script where the code has been executed. 1 = current function. (can be useful if you want to get the line where this function has been called from) https://www.lua.org/pil/23.1.html WIKI MTA: WIKI MTA debugging tutorial/information. https://wiki.multitheftauto.com/wiki/Debugging Edited February 12, 2018 by IIYAMA Example 2 15 4 Link to comment
Axel Posted May 22, 2017 Share Posted May 22, 2017 (edited) Very usefull, good job Edited May 22, 2017 by Axel 1 Link to comment
Hale Posted May 23, 2017 Share Posted May 23, 2017 (edited) Nice job, should be useful for all those in need of help. I'd also like to mention the outputDebugString 'level' variable consists of 4 different types: Quote level: the debug message level. Possible values are: 0: Custom message 1: Error message 2: Warning message 3: Information message (default) Edited May 23, 2017 by Hale 1 Link to comment
pa3ck Posted July 7, 2017 Share Posted July 7, 2017 Great tutorial, although it should be common sense... But I'm amazed by the number of people that come to the forum looking for help without any type of debug done by themselves... should be a sticky post. 1 Link to comment
Moderators IIYAMA Posted August 5, 2017 Author Moderators Share Posted August 5, 2017 I think the problem lies with the mentalmodel of people that just started with scripting. The concept is simple, but for the ones with no guidelines it is required to be creative to come to up with those logic solutions. And a lot of people do not understand that creativity is key to programming, which is kinda funny. It might be a little bit dangerous to say this: People who fail at programming even though they understand the pieces of code are mostly not creative enough to put it together. This doesn't count for every individual ofcourse. 2 Link to comment
Moderators IIYAMA Posted November 16, 2017 Author Moderators Share Posted November 16, 2017 I updated some content. If you find some typo's/etc Feel free to mention it. It is not my mother language after all. Thank you for the support guys! You are the best! 2 Link to comment
DiGiTal Posted December 30, 2017 Share Posted December 30, 2017 Why its limited to use the outputdebugstring ? Or i didnt understood 1 Link to comment
Moderators IIYAMA Posted December 31, 2017 Author Moderators Share Posted December 31, 2017 16 hours ago, DiGiTal said: Why its limited to use the outputdebugstring ? Or i didnt understood It isn't limited. But you may lose overview if you spam it from too many different components. Link to comment
ShayF2 Posted January 12, 2018 Share Posted January 12, 2018 (edited) On 5/17/2017 at 08:35, IIYAMA said: Debugging Do you know what debugging is? You might think you do, but unfortunately (in my opinion) only ~15% of the scripters in the community do know the full definition of it. Many people think that debugging code is the same as looking in to the Debug Console and waiting for warning + errors to show up. That's indeed debugging and yet it never provide all information you need to build your scripts. It only can say what goes wrong at a certain line. With other words, the Debug Console by default will only show a limited amount of mistakes you have made in your code. So what is next? You fixed all warnings and errors and yet it doesn't work. You start with making your code visible! I guess 70% would think: Making code visible? Ehhh how??? Let me write it down a little bit different: By using Debug Information making the behaviour of the code visible. I guess 50% would think: Eh what? behaviour of code????? Let me give you an example. Example: (1) outputDebugString("the script has started") -- < this is a debug line if true then outputDebugString("code works here") -- < this is a debug line else outputDebugString("code shouldn't be working here") -- < this is a debug line end Debug console "the script has started" "code works here" The debug console is NOT information for players it is information for YOU developers! BTW this is a debug line outputDebugString("test") -- < this is a debug line In this case it is just a piece of code that shows information in the debug console. Example: (2) local playerName1 = "snake1" local playerName2 = "cow" if playerName1 == playerName2 then outputDebugString("players playerName1 and playerName2 do share the same name. Name: " .. tostring(playerName1)) -- < this is a debug line else outputDebugString("players playerName1 and playerName2 do NOT share the same name. playerName1: " .. tostring(playerName1) .. ", playerName2: " .. tostring(playerName2)) -- < this is a debug line end Debug console "players playerName1 and playerName2 do NOT share the same name. playerName1: snake1, playerName2: cow" Easy isn't? The concept behind this debug method is to see what the code does / doesn't execute. Is this method handy? It is actually the very basic of debugging, for code that doesn't contain any errors/warnings. I would say it is and it is a very powerful method too. It is also handy for people who do not know how to script. If you want people to help you with your code, but you do not know what is wrong with it. You can add those debug lines and point out to where the code stops working. This will make it more efficient for you and the scripter to work out the problem because the scripter knows where to look. How much debug lines do you have to add to your script? 1? 10? 100? 1000? You could start with around 100 debug lines and as you learn how to script, you can reduce it to 10+ debug lines. Too much debug lines are not always good, because they will give you too much information and it will cost time to manually filter them. So I recommend you to remove some of them afterwards. When you are finished with the tested code, you can remove 90+% of them. Feel free to disable them instead of removing them, if you know that you are going to need them again. For complex code, I use around 25 debug lines, SO DON'T HOLD BACK! Render events It is strongly recommended to remove debug lines that are executed on onClientRender/render events when you are finished with your code. Because that can have influence on the smooth fps.(It will not drop much of the fps, but it can make it feel unsmooth) Clearing the debug console? /cleardebug Know your tools: outputDebugString -- Show a message on the Debug Console bool outputDebugString ( string text, [ int level=3, int red=255, int green=255, int blue=255 ] ) --- outputConsole -- Show a message on the F8 panel. bool outputConsole ( string text ) -- client bool outputConsole ( string text, [ element visibleTo=getRootElement() ] ) -- server --- inspect -- Convert one mixed value to a string. string inspect ( mixed var ) --- print -- Show a message on the terminal / serverwindow / Debug Console. bool print ( string var1[, string var2, string var3...] ) --- tostring() -- Convert a value in to a string. (but for objects/elements, inspect works better) --- iprint -- Show a message on the terminal / serverwindow / Debug Console (convert multiple mixed values automatic to string, no need for tostring or inspect) bool iprint ( mixed var1[, mixed var2, mixed var3...] ) --- outputChatBox -- You can also debug with outputChatBox (even though it is less efficient) bool outputChatBox ( string text [, int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- client bool outputChatBox ( string text [, element visibleTo=getRootElement(), int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- server Debug message levels 0: Custom message 1: Error message 2: Warning message 3: Information message (default) Addition by @Hale https://wiki.multitheftauto.com/wiki/OutputDebugString Advanced tools: local line = debug.getinfo(1).currentline -- get the line of the script where the code has been executed. 1 = current function. (can be useful if you want to get the line where this function has been called from) https://www.lua.org/pil/23.1.html WIKI MTA: WIKI MTA debugging tutorial/information. https://wiki.multitheftauto.com/wiki/Debugging Hi, I saw this and I figured I'd say something. I've been scripting for about 5 years as of now and debugging code has always been testing what parts of the code work and what parts don't. Usually debug scripts come with panels showing what went wrong. Sometimes it didn't show anything and I had to use hard debugging messages where I would output certain values in chat, or print. Debugging checks for faults in your code before final initialization. Or at least that's what it's mostly used for. I suppose you could output data for admins to read, like he/she did this/that etc. Edited January 12, 2018 by ShayF Link to comment
Moderators IIYAMA Posted January 12, 2018 Author Moderators Share Posted January 12, 2018 (edited) Yea, exactly. Except it is technically most of it in that way is not meant for Admins in the form of staff. Because you do want to remove those once you are finished. Too much debug isn't good for the performance as well as keeping overview. If you want to log things for staff Admin, then I recomment you to use https://wiki.multitheftauto.com/wiki/OutputServerLog Which will keep your debug information clean, so you can focus on real error. Edited January 12, 2018 by IIYAMA Link to comment
FernandoMTA Posted December 8, 2023 Share Posted December 8, 2023 Useful: printing current function name: local function myFunc() print(debug.getinfo(1, "n").name); end myFunc() 1 Link to comment
Recommended Posts