I am making a game, and I am wondering if I should use FilteringEnabled.
Is FilteringEnabled really worth using?
What are the pros/cons?
I have a basic understanding of what it does, but I have no idea how to utilitize it. I know the basic goal of FilteringEnabled is to stop hackers, but are there other ways of stopping it?
For example, would those Anti-Hack scripts in Free Models truly prevent hacking?
1st: No, there is no other way to prevent exploiting. Use the tools that ROBLOX gave you, not the ones that were hacked together on free models.
I know ROBLOX has policies about using FilteringEnabled; to be livestreamed by ROBLOX, you have to use it, for instance.
Pros
Cons
GUIs (in PlayerGui, at least) must be managed by LocalScripts. This means they can't make changes to the world directly, or do things like issue purchase requests. You'll need to use RemoteEvents or RemoteFunctions to accomplish those things. (Script objects don't run in the PlayerGui, only LocalScripts)
In general, LocalScripts can't modify the world for everyone. That means if something is done by a LocalScript, any changes to the world have to be done by normal Script object.
If you have any reason to make certain effects local to a player, FilteringEnabled will definitely make it easier. If you are building from the beginning with FilteringEnabled, it isn't very much harder than without; just remember to test using a Server in Studio.
RemoteFunctions / RemoteEvents won't cause "lag" in a game -- they will cause latency. It takes approximately 100 milliseconds (.1 seconds) for your computer to communicate with the ROBLOX server (or vice versa). That means whenever you have to cross that gap, there will be around a .1 second delay. Keep this in mind and avoid many chains of them, and there won't be any problems. (Normal Script objects suffer from this already, but you don't notice, do you?)
FilteringEnabled would require a clear understanding of RemoteEvents and RemoteMethods as well as manipulating Local and Server Side scripts to work in your favor. Some people have made tools work with FilteringEnabled, some others just plan to risk it, it is your personal preference. Now if you're just making your place a show off of building and use very few scripts then I would recommend FilteringEnabled. If you're using a lot of scripts, then you must feel pretty confident with yourself and turn FilteringEnabled on, otherwise leave it off. For example at my base, I am using a lot of scripts to change a player's walkspeed, health, and I intend to add guns which I have tested in the past and have turned out to have no effect in FilteringEnabled, so I have implemented my own attempts at a AntiExploitation measures.
As for the AntiHack scripts you see in the Library, those are sometimes fakes, sometimes they actually work, sometimes they will just give you a list of known hackers only known to the model maker. You will just have to examine the scripts to see which ones supposedly work.
Unfortunately the only official ways to stop exploiters is when Roblox updates and patches a exploit, or activating FilteringEnabled.
YES! Use FilteringEnabled, always! That's my opinion anyways. You see, when you use FilteringEnabled you can entirely control server-client communications. This means, very little stress is put on the server(Well, as much as you wish). There are only a few things the server handles by default, one of which being default replication between characters in the game(Your client will be able to see other player objects walking about).
The reason why I believe FilteringEnabled is much better, and certainly more powerful, is it allows you to write your game you want to write it. It allows you to make your games much smoother, because being that you can write all the local effects yourself, and animate the other objects in the game yourself by communicating with the server, you can change a client's experience based on his/her preferences.
For instance, with FilteringEnabled it is much easier to add visual settings in your game. Some players may run your game on lower-end PCs, some higher. You could add a sliding bar in a settings menu to affect many things that your client has to deal with and render. Ragdoll times, flora count to be rendered around him/her, global player animation update times, particle counts for particle effects, and much much more.
In essence, FE lets you have more freedom with your game. Or at least, makes it much easier.
This discussion is preserved as it was. New answers, comments, and votes are closed.
6 comments
Blue, quick question. If I were to change the Walkspeed of my own character, or have my own character take damage, with FilteringEnabled Enabled. Would the changes to these properties show in the server?
I'll have to look into these "RemoteEvents" and "RemoteFunctions". Would they cause lag in a game?
M39a9am3R: That's a good question. I believe there is an exemption that the server WILL listen to changes to the Humanoid object; I'm not sure if WalkSpeed is included, though.
Alright, it seems that walkspeed works as intended with my scripts, just when I am out of oxygen at my base and I am supposed to be losing health, it is only displayed to the client.
ScriptingGuider made an anti exploit script mybe that stops fe bypasssers
good answer