I will hold you to that chicken recipe and report back the results.
In addition to
We should have a TL;DR, I didn’t bother to read it thread at all I don’t like walls of text, hence I have no idea what this feature can do
Your loss mate. Too lazy; didn’t read its a killer.
Can we have more announcements like this? Also, I’ll have to try the chicken recipe someday.
Wish we have more updates like this!
2019 will make Roblox great.
The Summary takes under a minute to read.
More AMAs. Usefull for the pesky little bug that occurs for seemly no reason.
Nice, this was my most requested feature during the internship.
But that means you will miss out on the killer chicken recipe!
The beginning but before the ‘flavour text’ gives the general summary.
I’m a vegan.
Yeah I realized that a little bit after
Thank you. Debugging was starting to remind me of the good old days of writing code for embedded mcu’s and sending output to a terminal app through an RS232 port.
So glad the debugger is being worked on! I had disabled it to simplify Studio (get rid of everything I don’t use). My problem with it is that breakpoints are not serialized (StarterPlayerScripts, testing using Play Solo), but this is a great start and I look forward to being able to use it some day! Unless they are actually serialized now (please tell me if they are!).
It should be the case, and has been for a long while, that if you open place P, set a bunch of breakpoints in scripts, close P, close Studio, re-open Studio, re-open P, the breakpoints you set should still be there.
If that’s not happening for you, please let me know with specific repro steps (it seems to work properly for me).
Is that what you mean by “serialized”, or am I misunderstanding you?
Sorry for confusion: That’s the intention of the “Summary” section at the top.
Should I make that shorter? Label it something different?
Thanks for your feedback. Even if you can’t consistently repro, please send along as many details as you can when you experience a crash related to debugger, I will see what I can do.
It is DEPRECATED because, as mentioned in the Summary, this business of having to choose whether debugger attaches to Server or Client is Not Long For This World: I am currently working on having separate debuggers, one attached to Client, one attached to Server. Then there’s no more preference, no need to choose, no setting.
So I wouldn’t spend much/any time developing features, plugins, whatever around the ability to attach debugger to Client or Server. Soon that will be a non-issue.
Just to clarify:
You mean that Play Solo is laggy (like just hitting play and running?)
Or you mean the debugger is laggy (like if you use settings and turn off Debugger then run play solo, things work fine, but if you turn Debugger on in Settings and run play solo, things are laggy)?
If it’s the latter (we’re sure it’s the debugger’s fault), could you produce a simple-as-possible sample place that demonstrates this problem and share it here?
No it was my mistake, but my suggestion is to put the Summary at the bottom and label it as “Summary (TL;DR)” as well, because usually it’s done like that from what I have seen.
Summary part is already good, I just happen to skip it automatically when I read it the first time
The crashes (and probably related useless stack info) during exceptions are really frustrating for me too, see the report here: Debugger stack in certain cases completely garbage . It’d be awesome to see this fixed.
If I have time, I will produce a test place, but in general its whenever you have a lot of modules/objects that are updated every game renderstep, you will get freezing up no matter what. It’s only when I have a really lightweight architecture/engine that I can use the debugger and not experience a freeze up.