This issue is only present in studio. (0.689.0.6890885 prod)
↑ client F9 console, studio F9 console looks like the below ↓
LogService.rbxl (73.8 KB)
What kind of bug is this? This is hilarious I will edit this let me experiment with this.
I have a theory the most likely reason of this happening is whenever you say code:
print("My Instance is: ",game)
That basically says to the engine don’t print the properties in a table print the value game.name.
But I assume LogService doesn’t know that?
For some reason you need Log Mode off to do this?
This even effects the console.
So your settings you do to Studios Console effect the in-game console.
Do you know what Log Mode even does?
Now that you mention it, unsure if there even is a bug, Log Mode (see last line) seems to have been automatically disabled for everyone in my team…(?)
I can imagine it isn’t intentional for the instance to be stringified, along with its references to other instances also being stringified? Especially that the issue is isolated to LogService
This could be a bug or not you are right about that. Log mode simplifies the output so I find it interesting that if you don’t have it enabled it doesn’t show that.
Hello, I can give more context re: this behavior and Log Mode.
So, back in 2020, we released the Expressive Output Window (you can see my name in the credits of the post! 
). This basically allows for you to print tables and instances, and have the Output window be able to expand and collapse those tables and link to the instances you printed, respectively.
There were people who did not like this, because it had the tendency to be slower than the previous behavior that didn’t do this. Log Mode essentially reverts the Output window behavior back to what it did before 2020 (no expandable tables or clickable instance links). It’s off by default because Log Mode off is the “new” behavior.
Re: this instance stringifying behavior, LogService does intend to do what it’s doing. The idea is that whatever LogService prints out to will not have the ability to expand tables like the Output window can. So, instead, when it receives a print event that is a “variant” object (like it could be expanded or is an instance), it will stringify the contents of that objects and send a MessageOut event with that data instead of what shows up in other areas. This behavior was added roughly when we added this new Output window behavior.
As far as the Developer Console goes, this also listens to print messages separately from the Output Window and LogService, so it handles print statements uniquely there.
Tl;dr this isn’t a bug, it’s a feature. LogService and Output Window cover different use cases.
The LogService behaviour is extremely confusing to me…
- The behaviour in studio doesn’t match the in client behaviour
- Why are instance references being recursively stringified, leading to the entire datamodel being output? (but then the output string getting trimmed due to length)
- “Log Mode” was seemingly disabled for everyone (in my team)?
I still cannot comprehend why “Log Mode” is a thing, its behaviour is the same inside of the output window, and negatively impacts studio performance with LogService…
I agree that the behavior is unclear. To answer each of your points specifically:
This is because they are completely separate implementations, and have slightly different use cases. Some of the behavior, like being able to expand and collapse tables, isn’t available in the in-client logging window.
As mentioned in my above post , “LogService does intend to do what it’s doing. The idea is that whatever LogService prints out to will not have the ability to expand tables like the Output window can. So, instead, when it receives a print event that is a “variant” object (like it could be expanded or is an instance), it will stringify the contents of that objects and send a MessageOut event with that data instead of what shows up in other areas. This behavior was added roughly when we added this new Output window behavior.” It’s not useful behavior in this particular case, so we recommend being specific with what values you want to print.
Also, re: the truncation behavior, according to LogService | Documentation - Roblox Creator Hub , “Content might also be truncated. Don’t rely on contents of events and messages emitted by this service for any important game logic.”
Log Mode is off for everyone by default because Log mode makes the Output window not have expandable/collapse-able tables or clickable instances, and we believe these features should be there by default and is worth the performance hit.
It is there because some people did not like the new Output window behavior, and requested that it be optional.
I understand it better now, thank you.
When Log Mode is enabled, it makes the output window, and F9 console, behave like it would in the client. With it disabled, it improves DX when working with pointers, but also affects LogService…
I still have some questions;
- With log mode disabled, why are instances recursively being stringified? Why not only stringify the printed instance? Why not just stringify the instance into its (full) name?
- One would expect LogService’s behaviour to not to change regardless of log mode’s state, why isn’t it like this?
Anyhow, the documentation for LogService and log mode should be updated to describe what behavior it changes.
With log mode disabled, why are instances recursively being stringified?
When LogService is sending a MessageOut event when the Message being sent is an instance and Log Mode is disabled, LogService imitates the behavior of being able to expand and collapse the contents of the object, like what the Output Window can do, to keep behavior between the Output Window and LogService as consistent as possible.
Why not only stringify the printed instance?
What’s being stringified IS the printed instance. However, the instance variables also include the instance’s parent, which includes the parent’s children, which is why you see recursion here.
Why not just stringify the instance into its (full) name?
Instance::GetFullName() does this. If that is the data you want, you should use this method instead of printing this instance itself.
One would expect LogService’s behaviour to not to change regardless of log mode’s state, why isn’t it like this?
This connection between Output Window and LogService was made because we believe it keeps consistent behavior between 2 features that support output logging functionality.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.