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.
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
Not sure what happened, but as of this morning, it appears that the expressive output window is mostly broken now.
@GeneralRelish if the team is in need of any system info or logs, feel free to have an engineer message me and I can provide them with any information they may need.
Thanks for reporting! A fix for this will be available shortly after this week’s release. We’re still working on the column logic so please report any other weird behavior!
For everyone in the thread reporting performance concerns - we hear you! Most of our current effort is going towards performance improvements. We will get close to parity with the old output window but there will always be a small performance cost incurred for the ability to print and dynamically expand tables. We recognize that this may be an issue for some workflows (e.g. logging), so we’ve included a ‘Log Mode’ setting that removes table printing and retains performance parity with the old output.
^ notice the columnar string of letters towards the right
Is this some sort of bug? I just opened the widget (docked to the right) and printed something.
The Log Mode feature is cool though.
Edit:
The mouse also seems to get stuck to the scrollbar occasionally, effectively preventing any input in Studio at all - might post a bug report when I get more details about its reproduction.
Looks like a combination of things - your Context column is word-wrapping but the column is really narrow so you get the string of letters. And the headers have disconnected so you can’t adjust. Bad, but we should have fixes for everything rolling out soon.
Please file a bug for the mouse-on-scollbar behavior if you can reproduce it. This sounds new and unfortunate.
This issue is happening to everyone on our dev team as well following todays update. The Expressive output window is now unusable and we have all been forced to disable it.
