Hello everyone!
I’ve recently been utilizing a heavy amount of RemoteEvents, and the folder I have organizing them has reached 41 individual RemoteEvents. For context, I’ve been scripting a framework for my group that handles everything under one umbrella. (Teaming, interactions, deaths, leaderstats etc.)
The Question: Is this too many? Or is this expected…
I saw much more remote events, but i recommend using sorted remote events in different folders, depending on it’s functions/accessibility.
It’s quite a bit, but I’m not too sure how much is too much. Maybe you can combine some? Like UnWeld and Weld > weld(bool weld) and false is unweld and true is weld
i am getting mentioned so much for this help
As long as these don’t get fired all at once or all the time than it should be fine. Many of the events could be combined using different arguments like @vlopste recommended, minimizing data sent across client and server.
I suggest only using 1 or a few RemoteEvents as every RemoteEvent, is an Instance so it will take up memory from both the player & server, though a flaw with 1 RemoteEvent is that the handling script could get quite unorganized, though if you are already using 1 script to handle framework I highly suggest changing it into only a few scripts.
Regarding what @vlopste already suggested, I suggest for handling something which can be enabled or disabled I suggest only using 1 RemoteEvent, for unwelding you would use weld(bool, obj1, obj2) with bool being false and for welding you should use weld(bool, weld) with bool being true
Take for example:
local function weld(weldBool : Boolean, object, object2 : BasePart)
if weldBool then -- Weld
... -- initial code
else -- Unweld
... -- Inital code
end
end
Regarding what @AC_Starmarine said do not send multiple events at once for example, you are sending multiple events together, Play to load in game and Team to switch teams, instead you could’ve used only 1 event for this example.
I didn’t even know you could do that, that helps a ton! Thanks!
It really doesn’t matter how many you have. As long as the architecture is clean and doesn’t force your code to branch a ton (this is why I don’t like using just 1).
It’s important to note that Remote Events also have their limitations. And if you send too many events within a short period of time it will get rate limited. While reusing a single remote event as best as you can is effective. It’s also important to know when you should use more than one remote event not only for the sake of organization but also because of the rate limits.
Agreed. I often parent remote events to objects for clarity so a normal game may have many remote events in the game. These don’t really incur any large performance penalty and tend to be nice from a coding perspective than having remote events that have to be routed globally.
Suggest using ONE because you can use this to use several at a time depending what it is.
This is only ONE remote event
-- // Server
Remote.OnServerEvent:Connect(function(Player, Arg) -- // arg is what the event is
if Arg == "BuyItem" then
-- // Whatever this is
elseif Arg == "Damage" then
-- // Then Damage stuff goes here
end
end)
-- // Client
-- To use the arguement you do this
-- If you wanna do "BuyItem" then you do
RemoteEvent:FireServer("BuyItem")
-- If you wanna do "Damage" then you do
RemoteEvent:FireServer("Damage")
That’s an interesting use-case. I’ve always put my remote events in Replicated Storage and had to reference them in a nightmarish way. However, the framework I built handles the references nicely. Of course there are edge cases where this isn’t handled nicely.
I take it most of your assets are self contained seeing as though you’re using the remote events in the object themselves? Or are the scripts still located elsewhere? Do you have an example of how that code might look?
A game like Bedwars and BSS would have hundreds maybe thousands (don’t think so though) so compared to that scale it’s not much. You could combine the remotes if you’d like to save up memory from the server and client for less lag, other than that I see no problem.
I do the same thing, it’s a bit harder for exploiters to find (in some cases) plus easier to find in studio and in general since its assigned to X.
Here’s a very simple scenario of the server-side code. Note this is very boiler-plate driven code, with the assumption we’ll be improving honking logic later on.
This is about the simplest version of networking I’ve got.
I’m glad you responded here, because I was going to link to the clip where you were talking about it being a myth that one event is better than multiple.
