The developer console is wonderful, but it has 4 big weaknesses:
- You can only view logs that have been created since you joined the server
- You can’t view others’ client logs (only your own) making it harder to debug issues other clients are having
- It’s impossible to filter out garbage warnings/errors (e.g. “Replication: Can’t create default object of type x”)
- It’s difficult to manage substantial amounts of duplicate errors/warnings
As I’ve needed to debug Zombie Rush issues, I wanted to get around these weaknesses. To do that, I’ve made my own server log history:
Here’s a brief look at the interface:
If you remember, I wasn’t a fan of those garbage warnings, so after a couple filter additions, here’s the server log:
I’m also able to view other clients’ logs as I mentioned earlier (and all of these are from before I joined the server):
I can also open up the stack trace by clicking the detail button at the bottom of the frame (you’ll also notice that those three errors have occurred more than once but have been combined):
The first release can be found here: Log Tracker - Roblox
This is lacking some features I’d like to include in a final release, but it’s still extremely useful in it’s current state, and there are no breaking bugs (mostly UX issues). Here are the following changes you can look forward to in future versions:
- Combine similar logs instead of local logs
- I currently combine logs for players/characters/UserId (e.g. Players.EchoReaper.Backpack and Players.Guest.Backpack both become Players..Backpack), but other similar logs are not combined
- Allow custom filters through the UI (currently has to be done through Lua)
- Separate HTTP errors into their own tab? (currently all blocked)
- Most of these errors are garbage, but if your game starts to see things like characterappearances not loading these might be a good thing to have
To use Log Tracker, require it either by ID (gets automatic updates) or take the (free) module, insert it into your game, and require that (opt out of automatic updates). From there, you can use F8 or chat “/log” to open it. I’ve also included a few API members that can be used so there’s no need to modify the module itself (makes it easier to update to later versions). Here are the current members:
#logTracker:SetPrivelegeCallback(callback)
Log Tracker isn’t able to be used by everyone (security reasons – it’d be bad if people could see how your scripts are breaking and potentially use that to their advantage) – by default, only the place owner can open it. If it’s a group place, only the group owner can open it – if there’s an easy way to check whether someone has place edit permissions for a group, let me know and I’ll change it to allow all players with place edit permissions.
Using this method, you’re able to specify your own callback to be used to decide who has access to Log Tracker. callback is a function that takes a parameter of player and returns true/false depending on whether they should have access to Log Tracker or not. Example usage:
logTracker:SetPrivelegeCallback(function(player)
return player.UserId == game.CreatorId --Only the creator has access to Log Tracker
end)
#logTracker:SetBlacklist(table)
Log Tracker has a blacklist that allows you to ignore specific, usually garbage, logs. If the log contains something in the (case-sensitive, string-only) blacklist, it won’t be logged. The default list is:
- onSoundLoaded cannot find
- We already gave out badgeId
- Replication: Can’t create default object
- failed to learn
- could not fetch
- Image failed to load
- Sound failed to load
- ContentProvider:Preload() failed
- http
- HTTP
- CURL
Example code to set the list to something else (must be a table and must only contain strings):
logTracker:SetBlacklist({"My custom blacklisted phrase"})
#logTracker:SetBlacklistExemptions(table)
The blacklist exemptions offer more power than just the blacklist. If a log message contains a phrase in the blacklist exemptions, even if it also contains a phrase in the blacklist, it will be logged. This can be useful for logging specific errors/warnings that contain generic keywords like “http” but also contain unique identifiers like “404”. The usage and restrictions are the same as SetBlacklist.
#logTracker:AddToBlacklist(table or string)
Instead of completely overwriting the default blacklist, you can add your own phrases to the default with this method. Example usage:
logTracker:AddToBlacklist("IgnoreMe")
logTracker:AddToBlacklist({"fooey", "gooey"})
Like the previous two methods, the table must contain only strings.
#logTracker:AddToBlacklistExemptions(table or string)
This adds the given string/table of strings to the blacklist exemption list. Its usage and restricts are the same as AddToBlacklist.
Some more info I’d like to add since proper UX isn’t in place yet:
- You can sort logs by clicking the column titles
- You can invert the sort by clicking the same column title twice
- Clicking “Log Message” sorts by chronological order (by when the first time the error/warning was logged – not the latest)
- If sorting by Receivers/Occurrences and the values are equal, the logs will be secondarily sorted by chronological order
- Receivers means the total number of clients who received the error. Occurrences means the total number of times that error has been logged. 2 receivers and 10 occurrences means that that error has been experienced by 2 people and they collectively generated that error 10 times (could be 1 time for PlayerA and 9 for PlayerB or 5 for each – it’s not specific)
