Lets say I have a Server Script, which detects a change in a BoolVal and then applies an effect to a Player, all of this is done within the script without the need for a RemoteEvent.
However, this could be done slightly easier by using game.Players.LocalPlayer within a Local Script with a RemoteEvent.
What difference is there between the two approches and would either have a security disadvantage over the other.
N.B. I have read alot the RemoteEvents can be attributed to many exploits within a game without proper checks (iirc Server Side) to stop a player from i.e. giving themselve HP.
Edit: I actually have scripts that do both of these things in my game, one system is with scripts, the other is with LocalScripts to a ServerScript via RemoteEvent. The one that detects the changed BoolVal uses a RBLXScriptSignal on Changed for the BoolVal.
Edit2: Even though I have marked a Solution, anyone else who would like to provide their “two cents” is more than welcome!
It all really depends on the situation. It’s different everywhere. If you have a lot of things to do that could be done on the client, then go ahead. But, if security is a big problem with the remote in this case, then by all means, do everything (that you can) on the server. If you can increase performance by handing things off to the client, then do that. With what you described,
I don’t really see the point here. I mean, if the client never is going to access that value in any way, then why would you do it in a local script? If the server is going to handle the effect, then do it on the server. Now, if there is a situation where the client for example wants to equip an effect after purchasing it in a shop, there is no way to avoid client to server communication
Another example, if it helps, the way I do my door system in one of my games. If I wanted to, I could make it so that when a client wants to open the door, the server does all the work tweening the door. In game, this results in laggy looking doors. So, what I did was have the server tell all the clients to locally tween the doors, then the server sets the final position. The result is smooth doors for the clients, and little work for the server. This isn’t related to security, but it can give you an idea of when to hand things off to the client.
