We’re excited to announce a beta for a number of features that make debugging in Roblox Studio more powerful than ever: something we’re calling Better Breakpoints. Breakpoints can now be easily customized to be conditional, log a message, and continue (or not) the execution of a program when they are triggered.
And even better, we’ve added the ability to quickly create preconfigured Breakpoints that utilize these settings for specific use cases:
- The ‘Standard’ Breakpoint preset, which is identical to the default breakpoint that can currently be set in Script Editor.
- The Logpoint preset, which logs a message without halting the execution of the program. No more print() statements needed!
- The Conditional Breakpoint preset, which halts the run of a program only when a given condition is met.
See below for an explanation of these new features, and info on some exciting new additions that are coming soon!
Breakpoints now have several properties that can be easily customized with the ‘Edit Breakpoint’ dialog:
Condition: A Condition is a Luau expression that determines whether or not the Breakpoint is ‘hit’ during the execution of a program. If the condition expression is empty or
Trueat runtime, then the Breakpoint’s action triggers.
Log Message: The Log Message action prints a message to the Output window when the Breakpoint is hit. It works like a print() statement within a Script. Logging a message is ideal for when some value or statement needs to be outputted over the course of running a program, without interrupting the execution itself. While not a requirement, Log Message is thereby most useful when Continue Execution is enabled.
Continue Execution: The Continue Execution action determines whether or not to halt the execution of your experience when the Breakpoint is hit. Continuing execution is valuable when you want information about how a program is running without interrupting the run itself. As mentioned above, this is most useful when used alongside the Log Message action.
Breakpoint presets allow you to create Breakpoints with settings preconfigured for common use cases. When you select a preset by right-clicking to the right of a line number on the left side of a script, a Breakpoint with the corresponding settings is inserted. You can further customize the Breakpoint after you create it.
‘Standard’ Breakpoint: Shown as “Breakpoint” in the context menu above, a ‘Standard’ Breakpoint is identical to the default Breakpoints that currently can be set in the Script Editor. It doesn’t have a condition and doesn’t log a message. It halts execution when it is hit. It’s ideal for when you want to examine the state of a program at the moment a certain line is run.
Note: ‘Standard’ Breakpoints can still be added by left-clicking on the left side of a Script.
Conditional Breakpoint: A Conditional Breakpoint has a conditional expression that determines whether or not it’s triggered when it is hit. It halts execution on trigger, and doesn’t log a message.
Logpoint: A Logpoint outputs a message when it is hit. It does not halt execution when it is triggered, and does not require a condition by default.
As a new feature we proudly introduce into Studio Debugger, Logpoints offer brand-new functionality to debugging in that they can entirely replace debug-related printing. Any print() statement used to log some value during a program’s execution can be swapped out for a Logoint, including any conditional statement that determines whether the print() statement should be executed.
We’re working on several additional improvements to Breakpoints:
- The Breakpoint Widget will be updated to reflect the status of Condition, Log Message and Continue Execution
- The ability to specify the DataModel as a Breakpoint setting, allowing for intuitive use of the DM context features introduced by the Universal Breakpoint Beta