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!
New Features
Breakpoint Settings
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 True at 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
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.
Coming Soon
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
As someone who’s been following up on these new features (esp. logpoints!), I’m super thrilled that they’re finally in beta!
Now that it is out, I can finally also post some of my suggestions that I’d love to see implemented:
There should be a keybind shortcut to allow for easier insertion of a breakpoint / logpoint on the current line you’ve selected. Currently it’s a bit tedious to have to press the relatively small space, right click, select to insert a breakpoint and yada yada. Implementing a keybind shortcut for this would make the process so much easier and intuitive in my opinion.
Allow for us to save breakpoints / logpoints - either be it relative to another line, or on the absolute scale in terms of the line it was inserted on. I find myself adding print’s everywhere that I keep on adding and then removing because I don’t want clutter debug code, and so allowing to quickly toggle debug points on and off again would be an amazing feature.
Overall, I’m super thrilled for the love which the debugging process has been getting, but for now it’s easier to keep doing something that’s faster - there isn’t enough incentive to stop practicing something that’s basically muscle memory at this point.
Adding onto the above point regarding intuitiveness, I would definitely be interested in seeing an “incremental” logpoint system, where you can simply press a couple of buttons to automatically insert print(1), print(2), print(3) etc., all in a numerical order going off their insertion order - along with a possible prefix / suffix?
I discovered recently that VS can log on a breakpoint and I use this almost constantly already. Logpoints are a huge addition that I will be using all the time.
This is great!
What do you think about a toggle to enable/disable all breakpoints per individual script?
Often times I comment out prints used for debugging so that the output doesn’t get clogged. If I could simply enable breakpoints when I need to debug a specific script and afterwards disable them that would be extremely useful!
These are very welcomed additions! Especially logpoints <3
It would also be helpful to have breakpoints for debug.profilebegin() and debug.profileend(). This would help to quickly debug execution times using the microprofiler without having to litter one’s code base with debug method calls or endTime - startTime prints.
I feel like this would be more trivial since anything under < 50-100 microseconds would no longer produce accurate benchmarks or results and have too big of a margin of error. Thus, you should use Boatbomber’s benchmarking plugin instead.
This is wonderful and should considerably cut down time spent debugging!
However, one thing I really desire with the breakpoint system in general is to be able to break at breakpoints in Local Server tests. Currently, breakpoints do not work at all in them. If pausing execution is more complicated to implement for Local Server runs, then I feel that these new logpoints with the “Continue Execution” option checked could work in in them at the very least (currently, even those do not).
I hear you!! Actually, we consider logpoint as a stepping stone to enable debugging in local server, leveraging its “continue execution” attribute as you mentioned.
There are still some technical difficulties we need to address, so it was not in the coming soon section of this post yet. But we are working on it!
Boatbomber’s benchmarking plugin is great for comparing small functions, but games are complicated and unpredictable; the microprofiler is the best way to inspect your code in real time on live servers. Lowering the effort required to create and toggle debug.profilebegin() and debug.profileend() calls would make using them a lot less tedious.
Since it’s unpredictable & arbitrary as you mentioned, I believe a better request would be to see all script execution code in the microprofiler - I.e., not just RunService event callbacks which you’ve tagged with the debug.profile functions, but rather being able to see the (major) impacters without having to spend time finding it out by yourself.
This update is amazing, your script editor is becoming better and better every update. This update is going to save I and my other’s time by the dozens.
Thanks to everyone who worked on this amazing update!
I haven’t tested the demo yet, but from a UX perspective log points would be a lot more useful if they would auto create a message with all of the variables being read in that line, or at a minimum, the line being executed itself.
This looks awesome! Will have to give it a try later, maybe I can finally ditch the old “caveman debugging” method if just chucking print() statements everywhere and constantly re-running the game.
