Is it possible to use one Remote Event for multiple scripts and variables?

Help and Feedback Scripting Support
#1

Is it possible to use one Remote Event for multiple scripts and variables?

3 Likes
#2

Yes what I like to do is have one script handle the remote event and then call a function in a module wi the value passed in

--local script

local remote = remotePath
remote:FireServer("PrintHello")
--Server script

local remote = remotePath
local module = require(modulePath)

remote.OnServerEvent:Connect(function(plr,passing)
   if module.Functions and module.Functions[passing] then
      module.Functions[passing]()
   end
end)

--Module
local module = {}
module.Functions = {
    ["PrintHello"] = function()
        print("Hello")
    end,

    ["PrintHi"] = function()
        print("Hi")
    end,
}

return module
3 Likes
#3

Yes, it is.

-- Client:
remoteEvent:FireServer(identifier, args)

-- Server:
remoteEvent.OnServerEvent:Connect(function(player, identifier, ...)
    -- You can then use If statements to see which function should handle it.
    -- The "..." contains all variables, so calling function(...) would send all 
        -- variables apart from player & identifier.
end

While this is possible I wouldn’t recommend it.
I did this a lot initially, but I have since moved away from this. I found that it caused too many maintenance issues down the line, and makes everything more confusing.

EDIT: Using the solution above has worked fine for me. I do however not define the function within the table, as I find it makes the code less structured.

1 Like
#4

Yes, you absolutely can. However, sometimes you better use another remote. [Depending on your situation/ script]

#5

I plan on doing it for buttons that all have the same Parent, so i think it should be okay

#6

What do you mean by “It caused too many maintenance issues down the line”?

#7

Sorry for the following rambling
I might have utilized this in a very poor way, but the structure I went with was something along the following:

-- Client code
remote:Fire("FuncName", param1, param2, param3)

-- Server code
remote.OnServerEvent:Connect(function(plr, funcName, ...)
    if funcName == "Func1Name" then
        func1(...)
    elseif funcName == "Func2Name" then
        func2(...)
    ... -- More if-statements
    else
        warn("No function found of name '" .. funcName .. "'."
    end
end)

This works, but since everything is going through one pipe it’s things tend to get messy, and they did. Adding new things sometimes conflicts with other things, which causes issues the more things are connected.

If you want to have a smooth programming experience, make your things very modular. You should be able to complete a code then forget about it more or less. Once it’s done it’s done.

I can however imagine this is a very good way to do it as long as you have planned ahead. It’s probably a very good solution for completed projects. It’s a neat way to structure everything once it is done.

However, if you are like me, developing with this becomes nothing short of a nightmare after X alterations to some functionality. My issues with it are mainly related to how I experience developing with this. So take my opinion with a grain of salt.

TL;DR
This style has worked very poorly for me when changes are made. This solution will most likely work well on projects with few/none changes. [Changes as in changes to the base structure]

– edit: added TL;DR

1 Like
#8

What do you do instead of this?

#9

I usually use different events instead, however I keep them in a folder for the specific task. Instead of (for example) using InventoryRemote and passing in various funcNames to get my desired functionality I would create an InventoryRemotes folder with the different functionality calls within it. It gets rid of all the code required for translating funcName into an actual function.

I’m not sure this is the best way of doing it, but I have found this to be a better way of doing it. Using the other solution requires you to first of all conceptualize a system, and then implement it. My current method skips this step and jumps directly to implementing the features.

I do however still think [the 1 remote version] can be a good solution when wrapping things up. Using 1 remote is, after all, less storage resources, but keep in mind it requires more computation.

– edit: grammar, phrasing

#10

I used to do what you were doing with the elseifs and the different remotes, each cause performance issues. The reason why elseif is bad is because depending on how many moves or “functions” there should be, it will take sooooo much time before it even checks if the string you pass in is the correct one. For example if you have string D it will not run until it goes through whether or not it is A, B, or C and on a large game scale with many players it affects performance. Same with the remotes. That why I use modules for key indexing since it assumes it is already there, when doing [“D”] = function() instead of elseif D it is basically making it key indexing instead of table.find if that makes sense

The only reason you think this is a better way than the other is because it uses seperate remotes and it calls a single function which is similar to the modules in that it calls a specific function in a table of functions instead of constantly going through all of them to check so in a sense they are legit the exact same reason they both work out fine

1 Like
#11

What are your thoughts on modules like AeroGameFramework or Knit that encapsulate them?

#12

I have not heard of those. I’m more familiar with other languages, and have so far not used anything not made by me or Roblox scripting-wise in Lua.

But even from not having used them nor even heard of them, if they are well-used it’s probably for a good reason. But everything has it’s pros and cons.

I can look into them if you wish, but I’m sure you would be able to come to a good conclusion yourself.