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.
Thank you for Logpoints! This is a super awesome set of features and I can begin moving over a bunch of annoying debugger logging stuff over to this asap
One thing I am interested in though is allowing developer access to the DebuggerManager() API methods via plugins - there is a lot(1) of developer(2) support(3) for this(4) and it seems like a very easy win! The use case would be studio integrations like Rojo or VS Code Output Sync which would benefit from being able to reflect the current Debugging state and set breakpoints from scripts edited from outside of the Studio environment. This setup is currently used by some big players like Adopt Me and Jailbreak and I’m sure they would appreciate this streamlining of their workflow!
Many thanks for your hard work on making our lives easier to enjoy and create stuff on the platform. Looking forward to watching RDC after the fact to learn more about what is coming!
One step closer to visual studio, awesomesauce.
I am curious though, are there likely to be any improvements to performance while in debug mode?
A few times when I’ve been trying to step through code and read values or logic - sometimes the intellisense (or whatever it is called) either doesn’t appear or takes a few seconds to do so.
