See that output? That’s called “spam” It happens once every second in this game. In my game, which not only reports all the output received, but also creates a bajillion new outputs when it finds the report and tells the client, it’s impossible to join.
The attached place shows that it occurs when the client tries to change stuff in the PlayerGui, something already filtered no matter what. All we need is a single message warning us that filteringEnabled is indeed enabled when the server starts.
That is it, unless we turn on “verbose” mode or something. So please, let me use FilteringEnabled, by filtering some of the output spam we’ve got here.
I’m writing a local sandbox script (with a serverside handler) that does some awesome stuff.
The localscript connects to the serverscript, and gets an unique accesskey so only that localscript can access serverside stuff.
There are 2 tables, sort of whitelists: One for PropertyReplication, the other for InstantiatingReplication.
A small example:
-- Inside the sandbox script
local ReplicatedProperties = {
["Value"] = true;
[workspace.BasePlate] = {"BrickColor","Reflectance","Transparency"};
}
local ReplicatedNewInstances = {
[game:GetService("ReplicatedStorage")] = true;
[workspace] = {"Part"}
}
-- Inside a random localscript
while not Instance.Sandbox do wait() end Instance.Sandbox()
Instance.new("StringValue",game:GetService("ReplicatedStorage")).Value = "Succes!"
Instance.new("Part",workspace).Anchored = true
Instance.new("StringValue",workspace).Value = "Trololo!"
Result (from serverside view):
A new StringValue in ReplicatedStorage is added, with as Value “Success!”
A new Part is added in workspace, but Anchored isn’t set (not whitelisted)
(Anchored is however true on the client, thuss weird physics, oh well)
There is no new StringValue in workspace, as it isn’t whitelisted to be created.
(The StringValue however, is in the workspace locally)
Also while testing this, I noticed that a replicated part, if you set Anchored true localside, has some nice effect.
If you set the CFrame locally, then serverside, it’ll fall serverside, but stay at the same place localside.
You have now a sort of “local part” which is actually replicated.
And the spamming output makes the game unplayable. We call that useless. :P[/quote]
No, it doesn’t. Players will never see the output if you’re developing properly, and it is possible to ignore it, annoying as it is.
It needs to stop, but it does still serve its purpose. You sound really whiny in this thread.
And the spamming output makes the game unplayable. We call that useless. :P[/quote]
No, it doesn’t. Players will never see the output if you’re developing properly, and it is possible to ignore it, annoying as it is.
It needs to stop, but it does still serve its purpose. You sound really whiny in this thread.[/quote]
Because it spams the output, it pushes away all useful errors and warnings making it near impossible to debug if a script breaks during output spam.
Apart from
a) Whenever a new message is generated it resets to the bottom of the output window
and
b) If you actually read the OP, his game relays the outputs to his client so he can read them in game, but the output spam combined with this causes the game to slow down and stop.
That would add client load, not decrease it.[/quote]
That’s what I did and my performance load is immeasurably small, plus it only does anything when LogService fires its event.
EDIT: On the topic of performance, it should be noted that the performance loss associated with displaying all of those output warnings is far greater than the performance loss of the vast majority of whatever you’re trying to do. If performance is going to become the topic then we need to add that to the list of why these warnings need an off switch.
And the spamming output makes the game unplayable. We call that useless. :P[/quote]
No, it doesn’t. Players will never see the output if you’re developing properly, and it is possible to ignore it, annoying as it is.
It needs to stop, but it does still serve its purpose. You sound really whiny in this thread.[/quote]
I’m going to have to argue with you. It makes the game useless because it crashes the game. They don’t have to see it, but they certainly feel it. I can ignore it all I want until my studio fails to even respond.
That, good sir, as I have explained before, is why filtering enabled is currently useless.
Fun fact. PlayerGui does not replicate to other clients anyway. And with FilteringEnabled it does not replicate to the server! Those warning are the most useless things in the world!
I’ve uploaded / attached the file. It won’t crash your game (as I’ve set it to only change the color once every second), but you can see how annoying it is. It also tests local parts, which don’t spam stuff.
