Can't reliably set breakpoints with F9 nor with context menu

The option to set a breakpoint periodically disappears from my Script Editor window in Studio. F9 does nothing and there is no “Break point” context menu item on right click.

If I have multiple tabs open at once, I find that some scripts will let me set breakpoints in them and others will not.

Closing the file and opening it again fixes the problem. I haven’t been able to suss out a cause or create a 100% repro, but it is happening fairly often.

I have all beta features turned off except the one that stops Studio from killing itself when Roblox pushes an update.

3 Likes

I’ve been encountering this too - I thought I was doing something wrong.

Any commonalities that you have experienced that might identify the root? I don’t seem to encounter it with Collaborative Editing enabled on TeamCreate, but only in my own local games.

This is local only. I’ve never used TeamCreate.

I have noticed that sometimes the set breakpoint option shows up twice in the context menu. Looks like some sort of race condition in the GUI logic. Probably a smoking gun.

3 Likes

Thanks for the heads up on this one. Let me know if you get consistent repro steps. I’ll ask a QA too to hammer on this.

Also, when this happens, can you still set a breakpoint by left clicking in the gutter (in the space between the line numbers and the arrows)?

Hi Shedletsky,
When you are able to reproduce the issue again, can you share the .rbxl file or test place? Thanks!

I just had this bug happen to me again.

I’m editing a ModuleScript. I notice break points are not working. No “Insert Breakpoint” option in context menu. F9 does not work. Left clicking gutter does not work.

Save the file. Open it again in Studio. Now breakpoints in that script are working.

Since there’s no repro, I assume the file is not helpful. This file is totally different than the last file I had this happen with, so I don’t think it has anything to do with the content of the scripts I’ve been editing specifically.

Additional info: I was trying to set a breakpoint to track down a bug I had where a tool didn’t have the character as its parent. After closing/reopening Studio and being able to set that breakpoint that I wanted, my bug went away. On possible interpretation is that the breakpoint bug has something to do with the internal representation of the script not being 100% in sync with the text in the scintilla editor. Is that even possible?

Even More Additional Info: So it’s possible that I have just been staring at this code for too long. But I swear the code that runs when I press the Play button is not always the code I’m seeing in my editor. Is there an easy way for me to checksum both and confirm that is the issue?

2 Likes

Happening again today. Tried to set breakpoint in a Module Script while game was running. Didn’t work. Figured maybe Roblox didn’t support that. Stopped the game. Still couldn’t set breakpoint.

Closed file and opened it again. Was able to set breakpoint where I wanted.

I suggest instrumenting the scintilla editor to see how often the “Set Breakpoint” context menu item is not populated. 100% of the time when I have encountered this bug, that has been missing.

Again today I have the behavior where I had buggy code, wanted to set a breakpoint to inspect the variable, and once breakpoints were working again, the bug disappeared.

If I can’t trust that the code in my editor is the code that is running, debugging becomes very frustrating.

I don’t know if it will help, but I’ve attached the file I am working on. I’m trying to get all the original SFOTH swords to share a common base script so that if I put anti-exploiting spaghetti code in my game, at least it can all be in the same place. The base script implements basic sword behavior and allows overrides using function variables in a very hacky way because I don’t know how to properly write reusable code in Lua. I suspect something is up with how Studio is handling this Module Script which is required by half of the swords that I’ve managed to convert over so far which causes setting breakpoints to break.

New Swords.rbxl (51.8 KB)

3 Likes

I think I’m using require incorrectly.

I want to use it as an object factory. Every time I call require I want a new environment local to the script calling require. Instead I think it’s global and executed once.

This still shouldn’t effect breakpoints though.

3 Likes

If you’re calling require on copies of ModuleScripts, don’t do that - it’s kind of an anti-pattern that causes problems down the line. (Also saying this in case anyone else might be doing this)

As soon as a ModuleScript returns it will always return the exact same thing it originally returned, and never run again (that thing may or may not be what is causing some kind of shared state). If different environments require a module, they’ll each execute it once (command bar, script, local script).

Yeah. My code is not doing what I thought it was.

I just want to create a BaseSword class and have all my other swords inherit it.

I have no idea how to do this in Lua. Probably a separate discussion.

However, no code I write should be able to break setting breakpoints from the GUI, which seems to be happening pretty consistently in this file.

4 Likes

For that you might want to use some sort of inheritance pattern with metatables.

(For what it’s worth, I’ve always found breakpoints to be quite finnicky. Going to watch this thread to see where it goes…)

I’ve been really resisting learning how to use metatables. Seems like some Lua internal stuff I shouldn’t have to know about and the code looks really ugly. I’ll spend hours mucking around with syntax I don’t understand to try to implement something that modern languages have by default and it won’t be fun.

4 Likes

Had this bug again today. This time in code that was not requiring any Module Scripts.

Closing an re-opening the script’s window fixed it.

2 Likes

Still having this issue, this time in a LocalScript.

Saw this other post about it, looks like it has been with us for a long time.

1 Like