Yes!! It is I! Your breakpoints and opened scripts!
You thought you got rid of me when you closed that open place file! And in the past that worked just fine!
Well no more, mi amigo! If you open some script files and set some breakpoints, then close your place file (heck, you could even close Studio for all I care!!), when you re-open that place file later all of your opened scripts and breakpoints will be restored!
P.S. Robloxâs Lua debugger has API that can be used in plugins.
Its sorta unsupported, but crafty users can try to utilize it.
See: Documentation - Roblox Creator Hub
Place tab is placed at the end of the tab list instead of the front when re-opening places. Generally itâs preferrable to have script tabs listed after the place tab
Itâd be nice if the order of our tabs and which tab was active were preserved
Preserving folds would also be wonderful. Current behavior - before close on the left, and after re-open on the right:
Anyway, breakpoints disappearing was one of the major four blockers preventing me from using breakpoints â itâs great to see this change. Hopefully we can see debugging improved even further in the future so I can entirely stop relying on printing values out. The primary problem is that debugging isnât dynamic â if I find an issue with my debug configuration, I have to stop debugging, make the changes, and then re-run the game. For instance:
Iâm looking at a watched variable âaâ, and its value leads me to look at âbâ, which Iâm not watching and have to stop/re-run to watch âbâ (which can be catastrophic if itâs a difficult-to-repro issue)
Once I hit a breakpoint, I find that my script is breaking because of a value returned by a ModuleScript, and instead of diving straight into it, I have to stop the game, manually add breakpoints to the modulescript, and resume debugging. A more ideal behavior would be for me to dive into the ModuleScript, see that (a+b+c)/d was returning bad values because d was 0, and then tackle the issue from there
I have one string index added to a table on accident and now I canât find out whatâs wrong with it because the variable watcher doesnât show tables that have non-int indices, so I have to stop debugging, manually add a print check, and rerun the game.
Itâd be nice for:
All variables were automatically tracked like in Eclipse and other IDEs (with perhaps a way to mark some as âimportantâ so they show up at the top of the list)
Able to freely check watched variables of any scope even if Iâm paused at a breakpoint in a different script
Note that mouseover doesnât work for single-letter named variables. But for others it should always work now. You donât have to set up watch or restart. At least in the stack frame that the debugger is stopped in, it should just work immediately. This is a fairly recent fix so it may not have been noticed.
Ah, I never knew about that. Itâs definitely helpful, but the inability to see outside the current stack frame is still a major blocker. I use fairly modular code, so itâs a dealbreaker that Iâm restricted to a single module when the problem may have originated three modules up. Imagine only having the stack trace in the output return the last line, and thatâs what itâs like to debug with the watcher while using modules.
I have waited for so long to say this to you, good sir:
Bravo!
I have a question however - do breakpoints transfer over TeamCreate? Iâm not sure if they did before, however I donât have the opportunity to test it at the moment.
Sorry about the bump, but is it possible we could have the rbxl tab always load first? Having the place tab last in line when I load a game is just a tiny bit disorienting.
