The Debugger - Enhanced Watch Window

Sadly the same, as the breakpoint tool is cumbersome to use due to it’s nature of pausing the whole game - I find it much more intuitive to just add prints, which show where in the code it stops instantly, instead of bringing me into a whole other screen.

On a side note, I found a very… peculiar, bug:


What I was testing on:

4 Likes

The nature of breakpoint is to pause the execution, so showing “Rendering is paused for debugging…” is an expected behavior. The good news is, we plan to ship Logpoints in a few months, which will no longer interrupt the execution of the program but log a message in Output window. Stay tuned.

I can’t reproduce the white panes on my side. I suspect they are related to Roact plugin UI. Could you share your place file with me?

11 Likes

Great to hear! Sounds like logpoints would make debugging way easier than having to spam prints everywhere :sweat_smile:

As for the issue I reported above, it only occurred once, and I’ve restarted my PC since, effectively closing the file - sorry for being unable to provide any reproduction steps, as I have been unable to reproduce it since.

Edit: to clarify - even during that session, it only occurred once. Running again did not reproduce it, though I still had to close the blank widgets.

3 Likes

Sweet. I’d love if there were a way to select the Instance and view it in the Explorer and Properties windows. For cases where e.g. a turret has a “target” variable that’s usually someone’s Torso Part, I really want to know whose torso it is, and where it’s located via the studio selection box highlight. It would also be convenient for looking at other sibling instances, CollectionService tags, and shape/visuals of the part you can’t display in the watch window.

At least for me, I always keep the Explorer and Properties windows open on ~20% of my screen and try to keep my watch window small. So viewing Instances in the Explorer and Properties widgets would also be more comfortable and save screen space.

5 Likes

I’ve noticed that when I set a breakpoint at the start of a loop definition, the breakpoint will sometimes not be hit before the loop has run some iterations.

I’m always nervous about stepping into yield calls because of how often they result in crashes. It seems especially risky if I am spamming the step into button.

I love and frequently use the debugger, but these are the types of bugs that I wouldn’t report formally because I lack reproduction steps, and they’re seriously annoying. I’m very hopeful for this upgrade effort, especially for the stability improvements!

5 Likes

I can’t seem to get it to work. This feature would save me tons of time if it did work.

Am I doing something wrong?

I’ve tried selecting the variable in different ways but all it says “Symbol [variable name] not in scope”

3 Likes

I hope that you add a feature where it writes the amount of end(s) needed for the script to run

6 Likes

I am not a scripter so I wouldn’t understanding the update as much as a person who specializes in Scripting :laughing:

2 Likes

Good to know that I can debug code without littering it with prints now. Amaze

1 Like

When will the script editor be fixed so it doesn’t run at 1 fps while scripting in team create with nvidia gpu?

1 Like

For now, this is not interesting for me, and to tell you the truth, it even gets in the way of viewing the table’s contents. How to remove this table address from the watch view?

Loving this! I didn’t know how to use this at first but I finally learned how to use the debugger! Now I can define on how my scripts won’t run sometimes.

Only issue is that I run into this error! Which causes my studio to crash (not fully but takes a while to stop the debugging and executions)

Otherwise, great feature I must say!