I’ve been wondering how to use the client-server model in my scripts because I’ve recently come upon videos saying projectiles and animations should be on the client.
I can change attributes on the server and have clients notice this using GetAttributeChangedSignal.
I can use FireAllClients with the benefit of sending in parameters to the client and not having to reverse a changed attribute. The problem is, is that this is less performant than using GetAttributeChangedSignal.
If performance is imperative, I’d recommend using an UnreliableRemoteEvent, as it doesn’t have the performance hit of the normal RemoteEvent, while still performing essentially the same task.
Do not use UnreliableRemoteEvents for something like a projectile. Nor should they just be used as a supplement for normal remote events.
They have their purpose and use cases, you should not simply replace a RemoteEvent for an unreliable one without having a reason.
UnreliableRemoteEvents are exactly that, unreliable. They should be used when you don’t need confirmation that a client has received it, or do not care about the order in which a client receives the event. They can be dropped, skipped, and are not queued like normal remote events.
FireAllClients will work fine, the overhead on it should be the most efficient out of the three methods you aforementioned. However you will need to do additional logic to ensure a new client has the most recent parameters.
FireAllClients can get taxing on the server in many cases.
For instance, one player wants to play an animation using a tool that we want many other players to see, and those other players will also be using it constantly, so you don’t want to bog down the server with loads of tasks and animations to play.
Every time one player uses a tool, they fire to the server some info about the animation, and yhe server fires that info to all the clients. Now multiply that by a possible 60 players every second.
You don’t want to be constantly firing info back and forth. Simply telling the server to change an attribute will allow all other clients to see it immediately upon the attribute change, with much less delay than having to send another packet of information back and forth between every player in the server.
In the most respectful way: this is just a load of misinformation, not sure where you got any of this from.
If you’re firing all clients- then that’s a very minor overhead, it’s just sending a protocol to each client, this would not be baring on the server, and is how pretty much all modernized games do it.
Animations no matter what are going to be handled by whoever has network ownership of the animator object (within the humanoid), iirc- even if they are played on the server the associated network owner will handle the request.
Telling the server to change an attribute has more overhead then sending a protocol on ROBLOX’s end, the attribute itself needs to be stored in memory, and in no way should attributes be used as a means of networking, RemoteEvents exist for a reason, and attributes exist for a different reason.
When I have some time if you’d like I can write up a unit test to confirm this, I have done so in the past.