(The reason why I’m here is because @UWURAWRZDAD linked my post haha, thanks)
So to answer your question, Remote Events/Functions are meant for the client to make requests to the server. Something kind of like “hey let me attack” or “hey let me build this block here.” Remote Events are one way. You Fire them meaning you’re passing something from the client to the server or vice versa, and the target is doing something based on what you’ve sent. Remote functions are more like functions, and they can return stuff back which means that the sender will also wait for the target to return (this means you have to include a return somewhere in the callback).
When to use them is a bit of a hard question, but it also sort of ties in with “what is the proper way to use them” so I’ll get into both. Firstly, there are some dos and donts with remotes which are important if you want to make sure your game is secure.
- All communication can be seen to and from a client by that client (a client cannot see other client’s remote calls since they are purely Client > Server or Server > Client directly). That means storing passwords in your scripts or anything won’t work since they can see that data being sent.
- You should remember that an exploiter can see local script and module source (albeit a little limited), which means that they can see how you use your remotes of the client.
- An exploiter can also fire/invoke a remote at any time they please, change their arguments and return data, and even suppress communication as they choose.
- An exploiter can override the callback of a RemoteFunction (specifically, a RemoteEvent will not have this issue) if they choose and suppress responses, and because RemoteFunctions wait for a response, this will cause the server’s InvokeClient call to yield forever.
So basically, remotes are simply meant to be used for simple communication such as sending some information to the client, asking the client to do things, or asking the server to do things. I like to think about it like two people communicating. You don’t know what the other person is thinking, so they can tell you, or ask you questions, or ask you to do something. But at the same time, if you asked someone for their banking details do you think they’d give you them, no questions asked?
Your answer to this is most likely no, which brings me to my next point. You want your game’s way of handling remotes to be coherent. If you have a DeleteStructure event, do you think it would make sense to let the client delete a structure they don’t own? Or delete something that isn’t even a structure? You probably don’t, so in your callback you want to make sure you’re being smart about what you do with a client’s request.
A common example of where this can go wrong is with money. Say you have a Donate remote so that one player can make a donation to another. Well, you subtract money from the donator, and add that money back to the target player. But, what if the client sends a negative amount? If you don’t check this value, this will subtract a negative amount from the “donator” thus adding that amount, and add a negative amount to the target, thus removing that amount, so, basically an exploiter could steal money from other players.
As for your game, Touched events behave much like remotes in a way, but it’s not as obvious. When a player touches an object, they (usually) tell the server “hey I touched this object.” And the server can decide whether or not it should fire a Touched event. For anchored parts, and I believe parts with server ownership, when a client tells the server “hey I touched this object” the server usually ignores them and won’t fire a Touched event, and instead, will fire that Touched event when it thinks that they had touched the part.
I hope I haven’t included too much here, as it is quite a bit to read, and I hope this ends up giving you a better understanding of what remotes are/do and how to use them.