Today we’re launching new methods for LogService that give you more control over how you track information in your games. You can now use Output(), Info(), Warn(), and Error(), along with a generic Log() method.
Debug With More Context
We know it’s tough to scan through walls of text in the dev console to find out why a specific player’s data is bugged. These new methods aren’t just replacements for print or warn, they let you attach a context table directly to your logs.
How To Use Structured Logging
You can use these as drop-in replacements for classic functions. Don’t worry, we aren’t removing print, warn, or error.
Call the method from LogService: LogService:Output("Hello {name}", {name="Alice"}).
Pass arbitrary data into the context table: LogService:Info("{player} leveled up", {player="Bob", stats={level=42, class="Wizard"}}).
View the results in the F9 Developer Console or the Studio output window.
Accurate Analytics: Creator Analytics will aggregate your error reports based on the message template. This means your errors stay grouped together even when they have different parameters.
Visibility: The context table is fully viewable and expandable in the F9 dev console and Studio.
Future Integration: We’ll be bringing game server logs to the Creator Hub soon. Using these APIs ensures your templates and context tables show up there for easier remote debugging.
Known Issues
For the upcoming Creator Hub logs, large context tables will be dropped if they exceed 1KiB.
If we decide to change this limit, we will be sure to let you know well in advance.
Next Steps
We’ll keep looking for ways to make logging more powerful for you. Please share your thoughts on what other structured data tools would help your workflow!
Thank you for your continued support and feedback. Please let us know if you have any questions below!
FAQs
Can I still use print() and warn()?
Yes, those classic functions aren’t going anywhere. These new methods are optional upgrades for when you need more detail.
Is there a limit to the context table size?
While there isn’t a limit in the game engine, cloud-based logging features like Creator Analytics cap context tables at 1KB for performance reasons.
YAY!!! I have been waiting a while for the ability to print tables without needing to awkwardly print on multiple lines or convert it to json.
Also will each log type use distinct colours and will we be able to use custom formatting similar to RichText so we can highlight important details for easier reading?
It would be helpful if we could error with a specific traceback! When you error() you’re stuck to the traceback where that call was made. When I have an error handler, I often warn and include another traceback in the message, but being able to use the red text of an error message with an actual traceback attached would be cleaner.
Future Integration: We’ll be bringing game server logs to the Creator Hub soon. Using these APIs ensures your templates and context tables show up there for easier remote debugging.
can you please add a similar feature for plugins? right now, i’m using Bugsink to aggregate and manage error reports, though i’d rather have a native integration in roblox so i can avoid http permission pop ups which some people aren’t keen on enabling
I think introducing the ability to set a source would be nice, like a direct reference to a file or even line of code.
I notice currently it just lists the source as being from “Studio” even though when running within an in-session script. Maybe that might’ve just been an issue with how i’m using it though since I have it wrapped in a custom debug wrapper.
(When I say that, I’m referring to how with the output of a print, warn, or error the message would be clickable and would open up the script editor at the line of the call) The reason I say to “set” the source value rather than have it automatic is because with the current print system, if you have like a plugin running or have it be a temporary script (or have a wrapper) it takes more work to trace the log itself to identify the proper breakpoint.
TLDR: add ability to set, or at-least access Studio navigation metadata
Is this asynchronous or yielding/throttling? Prints can slow loops drastically, but sometimes it’s neccesary to log things in a loop that requires speed, for example an ECS heartbeat system loop. Yes we can make our own helper function that makes a new thread but that will trace back to the helper and its thread, not to the line the helper was called.
Very nice update! I can finally abandon my own implementation for a built-in one. Though…
There should be a category inside of the documentation that specifies which types get serialized and which do not. I kept running into an error Unsupported serialization type which does not state what is causing it to trip. I had to look through my code and comment out each log one by one and managed to narrow it down to a log that contains an Instance in the context.
I would also expect the error to specify what type caused it to trip, or to at least give me a proper stack trace rather than the internal one.
Here’s the error, both base_part and instance are of type Instance
I saw these on the developer docs some time ago and have been waiting for them to be available ever since.
It would be cool if we could pass a Color3 to output to get a custom output color.