Intuitive Debugger: breakpoint won't work if inserted inside a `MouseButton1Down` event while running the game

Bug Reports Studio Bugs
,
#1

Inserting a breakpoint while running the game works.
But interestingly, if I do the same inside a MouseButton1Down function, it is not immediately recognized by the debugger (and will only be recognized if I stop the game and start it again):

Here the original design for your convenience:
Baseplate.rbxl (45.2 KB)

1 Like
#2

Thanks for letting us know, we will take a look.

3 Likes
#3

One more detail: if the breakpoint already exists (turned off) before running, and then I run the game, if I turn this breakpoint on it won’t have any effect after clicking a button (MouseButton1Down).
And this will be for ANY breakpoint at any point in the script, not just inside the MouseButton1Down function. (But the opposite works):

#4

Actually, this is URGENT, as it is IMPOSSIBLE for me to debug a piece of code inside a loop, where I want to leave the breakpoint off and only turn it on for the moment before clicking a specific button.

But currently that doesn’t work, and I have to leave the breakpoint on BEFORE running the game; But then, Studio is stopping HUNDREDS of times unnecessarily at this breakpoint, just because of this bug…

Thanks in advance if this bug is given priority.

#5

Noted. We will take a look. The reason why this is happening is because Roblox Studio currently doesn’t map some GUI scripts correctly between play modes when they are cloned.
One workaround for this is to go into the Explorer while you are in Play Mode and open up the specific instance of the script under Players/[PlayerName]/PlayerGui/ScriptName, and add the breakpoints there.

1 Like
#6

This workaround works. Thank you!

#7

This bug has become quite inconvenient as I’ve been debugging a lot of things based on mouse clicks.
Do you have any predictions for the solution of this bug?

#8

We have a solution to this but it still needs approval, so I would expect anywhere from 1-2 weeks until a fix for this issue is out.

2 Likes
#9

Using your workaround, this happens, which is something I still can’t understand: the same LocalScript has a breakpoint set BEFORE running the game and another DURING game running.
I understand that an “Intuitive” debugger shouldn’t differentiate between a breakpoint created before or after the game runs:

image
image1107Ă—200 13.7 KB

#10

Yes, that is part of the fix for this issue that we are working on. Our debugger has trouble making the connection between original and cloned scripts in certain situations. The ideal behavior is propagating breakpoints on original scripts to all cloned scripts, and propagating breakpoints added on cloned scripts to original scripts. This fix is actually taking longer than expected, due to a number of edge cases, and we apologize for the inconvenience.

2 Likes
#11

Hello, after 40 days, apparently this fix lost priority, right?
However, it has been a lot of work. Every time I need to activate a breakpoint AFTER the game is running, I have to:

  1. In the Explorer window, look for the LocalScript instance that is inside the Players and open it
  2. Manually find the line and set the necessary breakpoints
  3. And after the project is stopped, ALL breakpoints set above are LOST.

I don’t agree to leave this bug on hold.

#12

This issue should be fixed now. Please try it out.

1 Like
#13

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