Is it better to have 10,000 remotes or pass your own number id "Enum.Value"?

Help and Feedback Scripting Support
#1

10,000 remotes is the max it will have at once but they can be deleted and recreated during runtime

Alternatively should I avoid creating and deleting the remotes?

1 Like
#2

Timestamped video for response:

I recommend watching the rest of the video as well, it answers a bunch of questions for beginner and intermediate developers.

5 Likes
#3

I already saw that he says to split it up because Roblox can handle the remote ids more efficiently but I’m asking about a specific case so I’m not really looking for a general “rule of thumb” :wink: response

#4

Why would you have 10,000 remotes? I can’t imagine each of them performs a different function. I think you should divide functionality in a way that makes the most organizational sense to you and not worry about pre-optimizing performance.

For example, which is better in this scenario does not depend on which performs better.
Case A: One remote TakeDamage with the parameter Damage.
Case B: 100 remotes TakeDamage1 - TakeDamage100 for every amount of damage an enemy could have taken.

Even if Case B was more performant it would lead to worse code organization and make the logic of your games networking harder to follow.

5 Likes
#5

I promise I would never do Case B

My scenario is this:

machine = Streamer.New(tostring(tile.Global),nil,{
	Name = stat.Name,
	Id = id,
	Owner = owner,
	CreationTime = getTime(), -- used for production
	
	Level = level,
	Xp = xp,
	XpLeft = xpLeft,
	
	Model = build,
	
	--Tile = tile, -- not using it atm and it messes up remotes bc cyclic table references
	Global = tile.Global, -- global position
	Health = health,
			
	MachineDataIndex = ind, -- index in machineData if its on an ffa tile to reference from client and when destroying, this will be nil if its not in ffa region
	
	Humanoid = humanoid,
	
	-- functions wont be streamed to client so its fine
	GrantXp = grantXp,
	Destroy = function(playAnimation)
		humanoid:Destroy()
		grid[tostring(machine.Global)].Machine = nil
		if playAnimation then
			removeBuild(machine)
		else
			build:Destroy()
		end
		Streamer.Destroy(machine)
		
		if ind then -- is ffa machine iff started as ffa machine
			machineFFAIndex[machine.MachineDataIndex] = nil
		end
		
		machine = nil
	end,
},{"Humanoid",})

In my game you can place machines down on tiles with a probably around 10,000 tile grid
The “state” of each machine can change and so clients need to know the changes made

So I could create remotes per machine, per tile, or a general remote that streams the data to the client with a parameter for the tile position

#6

Why not send states in bulk? Put all the stuff in one table and send it with one remote :stuck_out_tongue:

#7

I would probably split things up based on the expected action of the client.
MachineCreated
MachineEffect
MachineDestroyed
and so on.

I don’t think it would be unreasonable to do it per tile or per machine but with both those approaches you would have extra code that has to set up the remotes system. I would mainly focus on what makes the code easiest to understand for yourself.

#8

Doesn’t Roblox do that internally?

#9

The code you see there handles everything for the current approach I do
to update I do:
Machine(key,newVal,message)
and that streams to the client that a change is made at the key
client sees:

Streamer.Added:Connect(function(name,data)
local Machine = data
Machine:GetChanged():Connect(function(key,newVal,prevVal,message)

end)
end)

I really like this approach because it precisely avoids creating the different remotes for the different states

Maybe its just a personal preference but I hate connecting to remotes:

Network("MachineCreated"):Connect(function(data)

end)

Network("MachineEffect"):Connect(function(data)

end)

etc

#10

If the system works for you well, I wouldn’t worry too much about performance as the difference is likely negligible. If you encounter performance problems with you networking in the future, you can always experiment with ways to optimize it then.

#11

I mean I’d rather have a solid foundation than backtrack

#12

http://wiki.c2.com/?PrematureOptimization

Often people spend a lot of time optimizing things that will never be a problem. In an ideal world your code should be set up in such a way that you can change components such as networking without having to change other parts of your codebase.

1 Like
#13

I just have one remote function and one remote event for every player and also a global remote event so I can fire all clients. The remote event and function are both created once a player joins and then they’re attached to a script which handles any incoming requests. In the end the amount of remote events and functions in my game is numPlayers*2+1. This is helpful because scripts do not get throttled when many people are firing the same remote event constantly.