I’ve been using OnServer events for a while now. I’ve come across to a point where if I use a local script for a specific player, it seems to work just as well.
Even when running the game, the localscripts do their job at making: if anything happens, it only happens to the player locally.
It’s probably bad practice to rely on broken scripts, but why should I rely on remote events/functions that take so much more work to put together when I can just use a local script that will do just as well – if not, better?
Well remote events are just faster, the purpose of ROBLOX studio is to make games, but also a faster way to make them, for example instead of using a script to make blocks, we can just create them in the studio, or like, click detectors, never seen those before. ROBLOX is just trying to make it easy for us, so that’s how it works.
Character movement actually replicates to the server, so if you were to move a player on the client, it would replicate to the server
Anyways, to answer your questions, remote events are crucial with how the structure of the server-client is used in roblox. You can’t just change a value on the client and see those changes on the server. You need to fire the server so that it can change the value. Granted, you could just change values on the client, but that leaves your game heavily vulnerable to exploiters.
For some things, such as GUIs, it’s best to use local scripts, but when you need something on the server to happen to change a GUI, you should use a remote event.
For a specific example, you would need to use remote events if you were to create a trading system, as you need to go from one player, have the server as the mediator, and then to another client.
Do you mean teleporting as in moving the character within the same game, or using teleport service? Either way, both of those can be done on the client.
You should never change the humanoidrootpart position on any side of the game, as I’ve seen that it can get very messy with the character being detached. You should be using MoveTo() or changing the humanoidrootpart’s cframe, which can both be done efficiently on the client.
Some things belong on the server and some things belong on the client. It depends on what you are doing, why you need it, and how you intend to do it.
Give this a read, it’s a pretty good rundown on why stuff matters and what should go where.
Remotes are meant to be things to connect the client to the server, you should do it whenever you need a thing that can only be done locally to replicate to the server.
Somethings already replicates such as playing animations, sounds, and others.
But let’s say you want to do a gun, then you would need a remote event for that since:
1- You need to detect when the player does the action to activate the gun (doing it locally is faster)
2- The bullet needs to appear to everyone, otherwise, the player hit by the bullet would only take damage to the local player.
So there all you need to do is use remote, fire it when the player activates the gun, in the server you manage movement and damage.
This is the purpose for remotes.
Also there is the filtering enabled thats a part of it, basically it prevents most of the things of replicating when it happens in the client. Thats where remotes also enter, you use it to be able to do that in a different way.
“never trust the client”
-somebody somewhere at some time
when you have things like hitboxes, you do not want to trust the client 100%
same goes for things like chat prompts, magic casting, and in some cases even local stats like hunger, stamina etc
if you always fully 100% trust those clients, there is a very big chance that exploiters will take advantage of that
I wish I knew there was a limit on how many times I can use a remote without exceeding the limitations. The wiki previously stated it, but now the documentation for it is gone for somewhat reason.
It does depend on the data you’re sending, so there is no set limit per second. It would be useful to know whenever you find yourself sending a big piece of data (like a large table) frequently.
