Is it better to use a single remote for all players?

Help and Feedback Scripting Support
#1

So I was wondering, Is it better to use a single remote that is shared by every player (That is placed inside ReplicatedStorage), or is it better to create a unique remote for each player (That would be placed under the player object).

Would doing one method be more expensive?

I know this is probably a silly question.

2 Likes
#2

I think remotes are intended to be shared by all users that invoke it. There are no benefits having individual remotes per user other than organization.

7 Likes
A question about remote functions limit
#3

I’m pretty sure they both act in the same way, I’d assume doing one per client would be more expensive as the server has to deal with multiple instances instead of one. Either way, as long as your game is FilteringEnabled each client has their own copy anyway.

1 Like
#4

The way I do it, is I have a message manager script, one on server, and one on client, and they both send and receive through 3 remotes, one is just a remote event, then one is remote function going server to client and the other is remote function going client to server (the second 2 are in case I need to stop the script until I get a return value)

I have been using this system for a while, and have had no issues with it. Once set up, its a very easy and uncomplicated way to handle server <–> client communications.

2 Likes
#5

That sounds interesting.

What I had been doing was create a folder full of remotes with a specific name, then when that remote has been fired, the server or client will look through a folder of module-scripts under another folder for remote events and look for a module-script with the same name as the event that was fired. This means that it is really simple to add stuff in, and if you are doing any sanity checks, you can just do it in the specific remote.

I have now changed it from giving each player their own unique folder (that was cloned under their player object), to just putting a main folder in the ReplicatedStorage.

When I’ve used either methods I never actually noticed any performance differences, just wondered if using one method was better than the other. Now I’ve realised that there isn’t really much of a difference, but if I were to have a single folder for the events in the ReplicatedStorage, I would find that to be easier to manage.

A question about remote functions limit
#6

I recommend just using two remotes. 1 remote function and 1 remote event. You can use the first argument as a key for the remote to differentiate which function is tied to that remote. Here’s an example/unfinished module that I use in my games to keep from cluttering replicated storage and still keep efficiency.

--server side example
local Remotes = {} --define module

--define your remotes; this is based on where you place the single remote function and object
local RF = ReplicatedStorage.RF 
local RE = ReplicatedStorage.RE
local RFarr = {} --function array that is used to index for the proper return function when invoked
local REarr = {} --function array that is called when index for event

--creating new events and functions to listen to
function Remotes:newEvent(key, func)
    REarr[key] = func
end

function Remotes:newFunction(key, func)
    RFarr[key] = func
end

--invoke and firing client
function Remotes:fire(plr, key, ...)
   --this will be received by the remotes module client side to call the right function based on key
   RE:FireClient(plr, key, ...) 
end

function Remotes:invoke(plr, key,...)
   RF:InvokeClient(plr, key, ...)
end

--setup events/invokes
RF.OnServerInvoke = function(plr, key, ...) 
    --plr is default first argument, key is the index, and ... holds an arbitrary number of arguments
   return RFarr[key](plr, ...) --call indexed function with arguments
end

RE.OnServerEvent:Connect(function(plr, key,...)
    REarr[key](plr, ...)
end)

--Example: setting a new event
--Damaging a player; called from client RE:FireServer('DmgPlr')
Remotes:newEvent('DmgPlr', function(plr)
    plr.Character.Humanoid:TakeDamage(10)
end)

--Example: fire client for notification
Players.PlayerAdded:Connect(function(plr)
   wait(5)

   --called event function with key 'Welcome' to send a welcome msg to player
   Remotes:fire(plr, 'Welcome') 
end)

Because indexing is constant time (uses hashing), it is a better alternative to a bunch of if statements and is more robust and expandable. You can easily call for new events and new functions making your code less cluttered.

Keep in mind this is just a server side example. You can easily make the client side version with the main differences: it won’t take the player object as an argument, and there is not fire all clients or invoke all clients option. You can also make more options for this serverside module easily like fire all but one client or fire players in an array. This can give you more control over client/server communication without giving up efficiency. I hope this helps you!

[EDIT] - Sorry, I got carried away a bit. For the original question, you should just have 2 remotes for ALL players. These 2 remotes can handle anything using the indexing method.

9 Likes
#7

Would there be any throttling for just using two remotes compared to using more?

#8

Throttling limits are just for OVERALL remote usage or bandwidth for the device. So even if you have many remotes the overall network usage will be the same as just using two remotes. You can read up on other limitations of remotes here:

3 Likes