The new expressive output is pretty cool, but it is unable to print userdata. This makes debugging some of my custom objects more tedious because I cannot see if its a userdata or not. It simply displays “void”, not even showing that it’s a userdata. I really hope this isn’t intentional.
I really like this new update! Especially the print tables feature! Keep making this great updates!
After enabling the beta feature, the first thing that stood out to me was all the weird white outlines around the various UI elements. It doesn’t mesh well at all with the interface and looks bad when viewed side-by-side with the other windows. Example below:
Please either remove the outlines or make them darker.
Thanks for the new features guys!
It’s losing the column layout changes I made, every time I reopen my project.
Original:
Changed:
But if I close and reopen Studio, the original layout is back…
its not every single programmer
Thank you. For this pretty useful update.
https://gyazo.com/0f05ffe9de9ad8a78f68480f88cf5d87
This is honestly making me wayy uncomfortable than i should be…
oh awesome. this is so much better. can’t wait for this to come out of beta
This has been great to use so far! My only complaint is having to set it up again each time I open a new Studio window.
So, I like the idea for the output window becoming more useful. Some general comments.
- It currently seems really slow compared to the simple output. I was having trouble even scrolling through it. It also caused WaitForChild items to timeout. I had to disable this feature to keep working.
- The timestamp should include milliseconds as well.
- Because the debugger has not supported breakpoints on both the client and server for such a long time I have a logging class that all other classes inherit so the source column is not that useful for me. If I was using just print directly i can see the usefulness of it.
- I like where it is going, instead if messing with the existing print maybe make it a different function like ePrint() so you can control when you want to use it.
- Maybe consider a differ method builtin for tables like table:print(). Careful not to mess with our __tostring meta data though.
Not showing the keys correctly.
In my case, I have this table:
cell[1][2].Name="Inicializador"
cell[1][2].OrientationY=0
But when I print(cell)
I get:
Not showing the indexes [1]
and [2]
.
It was written in C++, not Roact AFAIK
My game crashed - would not load, with this enabled… i’m not at all sure why, but I do a TON of debug messages, when I test in studio.
This is pretty nice.
I was trying to make a plugin that did something similar to this, but then I found out that log service only returns strings, so it would’ve been hard to figure out what’s inside the table with just the default print plugin.
Could you color code the output more?
Something to distinguish keys from values
Google chrome’s debug console has it like this ^
Also, maybe a different color for all the different types?
One color for booleans
One color for numbers
One color for strings
One color for userdata
I really like the idea and concept, I want to use it more, but it’s current state is extremely costly. Even doing a moderate tracking print at 0.15 per a print causes massive performance hit on the tick.
Sadly, since deciphering the microprofiler is like forbidden knowledge hidden deep in the depths of the Elder Gods, I can not provide more information about what’s particularly causing it, only that I know I am not the only one experiencing it.
Maybe its a size of project thing, I am unsure. But I can’t use it for anything at the moment, but I really look forward to using it once those issues are sorted.
Side note:
– Who do I need to bribe with cookies to get an optional Color Pass in on a print to custom colorize the print?
Maybe something like warn but like
Alert(Color3, "my very very awesome print) ? Ya know, nothing CRAZY but this is one of those super low hanging quality of life features that would be AMAZING
Did you happen to have a humanoid.StateChanged type of event?
Edit: Sorry just re read your comment. Mine crashes in runtime whenever I have a humanoid.StateChanged event. I don’t know why but it’s really annoying.
I’ve tried to enable the new output window a couple of times, but always switch back within 15 minutes because the current output window is much more compact. The Warning/Error symbols in the first column don’t provide me with any new information that the printed text color doesn’t provide, the ‘Context’ column is useless as the exact same information is already displayed by the Green/Blue line in front of a print, and the ‘Source’ column can already be accessed in the current output window by hovering over a print.
Making the new ‘expressive’ output window really feel like just that - a version of the output window aimed at providing information in a prettier instead of a more usable fashion. I would greatly prefer the current output window to stick around instead of sacrifying 40% more window width to the same information.
Wow! this feature is so exciting!
Yeah, I’m having serious performance issues as well. I have an inventory system in my game and I use some debug printing only in Studio and I was wondering why I had a complete 5-second long freeze when I moved items around in my inventory… turns out it was the print() function taking 120ms each time.
That coupled with the window size is really making this unattractive to me. It actually makes my Studio viewport smaller than 600px (after Roblox’s scaling) on my 2K monitor, which triggers some “small screen” stuff both in core UI and my own UI. Kinda excessive. I think if this leaves beta, it really needs a way to disable the new stuff to be around what it was before in size. I just don’t find the new features useful enough to justify it.
Also, I’ve noticed that the excessive performance cost of print() is still there if I close the output window.
I like how the new window looks it provides information in a much more readable and easily accessible manner which is great, however I had to switch back to traditional output window because there are some performance issues with it. The print() command seems to have a huge performance cost and calling the command frequently significantly reduces performance and I get significant frame drops. Once this is fixed I will for sure be switching to new output window