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.