Breakpoints and Opened Scripts: I'm BACK!

(New family friendly edit!)

Oh, hello there. Surprised to see me?

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!

Bwa-ha-ha-haaa!!
Muah-ha-haaa!!
Snortle-snort-snort!
Tee-hee-heee!!

71 Likes

Thumbs up for the comical approach. :thumbsup:

So basically breakpoints save now? Sweet! :slight_smile:

7 Likes

Liked it, now let me read it.

You could announce the end of ROBLOX and everyone would still enjoy the post.

14 Likes

Still laughing at this
:thumbsup:

3 Likes

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: http://wiki.roblox.com/index.php?title=API:Class/DebuggerManager

1 Like

Previously open scripts re-opening when editing a place is amazing! Great change.

2 Likes

Feedback:

  • 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:

  1. 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)
  2. Able to freely check watched variables of any scope even if I’m paused at a breakpoint in a different script
  3. Full watch support for Lua tables
1 Like

Noted, thanks. More to come on this set of improvements.

1 Like

Why don’t you use mouseover?

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.

3 Likes

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.

Yeah. Even if you break in the wrong frame, though, you can still sometimes step up to get back into the frame the problem occured on.

I usually do

 if (error condition) then 
        print('x') 

and stick a breakpoint on the print statement so I can examine the state at that point.

1 Like

I know this may sound weird to say something as useful as this has broken my workflow…

May we have an option to close all tabs? I used to close my studio instances to close out all the script editors I had opened.

3 Likes

I have waited for so long to say this to you, good sir:

Bravo! :tada:

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.

Would be nice to have if not ¯\(ツ)/¯

They should persist if you transition to TeamCreate, yes.

This is great! :thumbsup: :thumbsup: :thumbsup:

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.

10 Likes

Odd, for me the rbxl tab is still always first. Are you loading from a file? Maybe it depends if you load from the site

Working on this right now.

3 Likes

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.