I understand that your specific error is pretty useless, but errors like that alone are not good enough of a reason to add something like this. If it was sorting/hiding script outputs by script name/hash it would get rid of problems such as misuse, but arbitrarily hiding an entire script’s source isn’t a good idea.
Except it is sweeping it under the rug. A script that errors is a malfunctioning script, so you should know about it. If you choose to hide errors from it, it means you acknowledge there is a problem but are hiding it so you don’t see it. Sweeping it under the rug.
The solution to your problem was already presented:
The code isn’t broken.
Say you got a punching script, it’ll complain when you try to punch and you don’t have an arm.
Say you got a camera script, suddenly it doesn’t have a torso, then it complains cause the character is deleted and the use of the camerascript is not suppose to cover that area.
Say you got ANY script that requires a full character to work. If there isn’t a character then it’s not suppose to work anyways.
Say you do a invokeServer and parts required to run it is deleted meanwhile it’s calling the server.
There are unlimited amounts of examples at which, if the script breaks, it’s because it’s not suppose to run in those scenarios anyways.
But place, you can just do if character:FindFirstChild(“Torso”) then
for every single frame? Really? That’s the worst solution ever.
But place, how about rewritting the whole logging system? Making your own logger?
No offence, that code was beautiful and could be used but I’m trying to be efficient here. I don’t want to do require in every script that I wish to print something in.
But place, just write :FindFirstChild, if and a thousand extra lines of code to fix these issues! Embedded everything in a cluster of findfirstchild and WaitForChilds making sure NOTHING ever gets reported! Not even the actual issues! That’s brilliant!
Every example you have there is an example of broken code. Your solutions are not limited to the first idea that someone gives you.
torso = obj:FindFirstChild("Torso")
while condition do
torso:Thing()
end
There, no “inefficient” FindFirstChild.
3 Likes
Why did you design your game so that you can lose an arm in the first place? Is this a game mechanic?
If so,
If you know this can happen, why doesn’t your script check for it?
These are all programmer errors. When you write code you should always check for this type of thing. Should you ever delve into the world of programming for operating systems, they don’t tend to play as nice when you try to access something that isn’t there 
Maybe what I try to advocate is poor scripting methods ;/
Ohwell, can you close this before the trolls arrive?
It’s getting dark, they be here any minute now.
Doesn’t this still work?
if not GG then
GG = getfenv()
return pcall(setfenv(1,GG))
end
Putting it at the top of the script should make it run in pcall.
(mind that other threads, like spawn,delay,coroutine,… could still log errors)
(oh and it also logs if you do wait()… there’s not really a good way for this without a sandbox)
(which is ironic, sandboxes sometimes have the problems they lose errors, especially stacktraces)
3 Likes
Perhaps somebody already mentioned this but I will add it on anyway. This sort of debugging is available in other packages. It can be useful at times but generally you should avoid it. Regardless I have only ever seen it handled directly from the debugging window. It is possible to blacklist certain pieces of code, however the difference is that it’s not a property. It’s retained in system memory until you exit the problem. If you accidentally hide the errors of a piece of code that breaks the program then you can easily fix it by clearing the black list and moreover it’s not saved to the program so the errors won’t be surpressed at run-time.
Trolls?
Sheesh, I didn’t realize using FindFirstChild was a bad thing.
2 Likes
A cluttered log should guilt-trip you into fixing your code to avoid errors. Proper error-handling is really good to learn. (And of course, learning how to avoid errors properly is even better).
6 Likes
Going to bump this since I feel even today this is still relevant, in our game blox royale we often get random roblox API errors that we can’t solve that we would rather were not logged in output.
6 Likes
Honestly, roblox’s scripts should have a different color or category, and their backend should have another separate color. Then they should allow filtering by color/type.
1 Like
Renamed thread from “New property: Script.Log = false” to current to make it easier to find for people in the future. (Make sure to focus feature requests around problems/desires rather than proposed technical solutions)
1 Like
I’m also affected by this, currently any kind of error will be displayed and logged through ScriptContext.Error and LogService.MessageOut which isn’t ideal at all.
We can’t differentiate which error comes from Roblox or our game’s code as easily which shouldn’t be the case for debugging.
3 Likes