[quote] There’s no reason why PlayerGui shouldn’t replicate to the server. I think that should be allowed as an exception to the replication filtering.
As the server, I think it’d be useful to be able to see what changes the client it making. [/quote]I think they did that to prevent server-side scripts from being run from PlayerGui.
PlayerGui and its properties are historically replicated to the server only. They are blocked with filtering enabled, but we overlooked the case where too much warning are generated when lots of animations are involved.
This week’s release will include a check box in settings to disable all filter related messages (similar to other network debug prints).
Next week’s release should include another fix where we will not even attempt to replicate PlayerGui when filtering is enabled. There will be no changes to functionality from user perspective, you just won’t see filter warning for PlayerGuis.
Uh, thanks! the checkmark in settings does not fix much though, as my game will still crash for other players. Sure, it makes debugging easier (and possible), but no, it won’t actually fix anything.
The PlayerGui thing is nice, that’ll fix the issue until I start trying to change other things in the game. Albeit, you may not want players to be using FilteringEnabled in a way that creates local data only, but crashing due to output spam may happen anyway. It is the nature of output. If you have enough of it, it will slow down your game. Unfortunately, we cannot affect this output if we want to modify certain items. It should either error, or just not output, but having a warning which will be disregarded is just plain annoying.
I’d request the output setting be stored with the game instead, or something, so it actually is useable.
However, the current proposal will work for now, anything is better than nothing.
It’s default not checked and will not print anything unless you enable it.