The Lua debugger is a tool designed to give the developer the same utility to a Roblox programmer as every developer expects from an IDE. It is enabled by default, however it can be turned off through Roblox studio’s settings menu.
What is a debugger?
A debugger is a tool that many programming environments have to help programmers check that their code is functioning properly. Many of its functions can be replicated with ugly print statements that verify when code executes, but a debugger allows you to put “checkpoints” into your code without modifying the code. In addition, the debugger has the benefit of stopping the application at the checkpoint, allowing the user to inspect the state of the program and even the values of certain variables during the execution of a specific line of code. For a Roblox developer, this could mean that instead of adding a line that says print(“Engine Starting”), and then print(variable.x) and print(variable.y) when testing their new vehicle start-up, they can cause the game to pause right as the engine starts up and verify the values that the variables are receiving internally.
Even if you prefer to use print statements within your code to verify operation, learning to use a debugger allows certain debugging capabilities that are unavailable to inspection through print statements. In addition, experience with debuggers creates comfort within a tool set that is widely used in a professional programming world.
Breakpoints are the checkpoints in your code. If a breakpoint is set, when Roblox is run (Play Solo, or the Run key) the system will pause when it tries to execute that line of code. To set a breakpoint you simply click to the left of the line of code you want to pause the system. This will create a red dot which indicates you want your code to break there. Once this is set, the next time you “Play Solo” or “Run” your game with this script inside it the game will pause right before executing this line of code. You can remove a breakpoint by clicking on it.
You can see all the breakpoints you have set by clicking on View > Breakpoints. This will open the Breakpoints window. From here you can individually turn on and off breakpoints, enable or disable all breakpoints at once, remove breakpoints, and see which scripts your breakpoints are in.
Stepping Through Code
When a script is paused at a breakpoint, you can continue executing the script one line of code at a time. Stepping through code allows you to closely monitor how variables are changed and which functions are called. There are three ways to step through code: Step Into, Step Over, and Step Out:
The Step Into button moves the debugger into the function on the current line. If there is no function on the current line, the debugger will move to the next line.
The Step Over button moves the debugger to the next line of code, not moving into functions.
The Step Out button moves the debugger out of the current function and to the next line of code after the function was initially called. If the current line is not in a function, then the button will move to the next line.
If you want to stop stepping through the debugger and want the game to resume playing, click either the Play Solo or Run button (whichever you used to start the game in the first place).
Watching a variable
You can also tell the system to watch a variable, meaning to keep track of it’s value when you hit breakpoints. This allows you to check what kind of changes a variable goes through as it navigates the breakpoints. To add an item to the watch list you simply have to highlight a variable and right-click on it in the script view and hit the “Add Watch” context menu item. Alternatively you can click the Add Watch button and type in the name of the variable. This will automatically retrieve information about the state of the variable under watch during breakpoints.
The Call Stack window can be used to see where in your code the game currently is (when paused or at a breakpoint). If the current line of code was called from a series of functions called from inside functions, the Call Stack will show the order the functions were called in, along with the Script and line number where the call was made.
To illustrate how this all works, here is a basic script.
print "Hello world!" v1 = 1 v2 = 2 v3 = v1 + v2 v3 = v3*2 print(v3)
When you add a breakpoint at line 1 and line 5 and hit Run, studio should Run and then pause right before printing “Hello World” at the output window. The scenario should look a lot like the scene on the left. You should also now see the call stack, which should provide a visualization of the current script data-structure as it looks during execution. Since our script is very simple, and no process is embedded, our call stack will be a single line.
Hitting run a second time should stop the script right before the variable v3 is doubled, and if you look under the watch window you should see the v3 correctly equals 3. Hitting Run one last time will print out 6, displaying that Breakpoints pause the script right before executing the line they are on.