For example let’s say I have a remote function and I handle it using different cases
function remoteFunction.OnServerInvoke(player, case)
-- Handle different cases based on the input
if case == "Case1" then
-- Perform actions for Case1
return "Case1 executed"
elseif case == "Case2" then
-- Perform actions for Case2
return "Case2 executed"
else
-- Handle the default case
return "Default case executed"
end
end
Or is it better to seperate them? Because I now some remote functions I’ll be using will be doing similiar things so I thought just keeping them in one single remote function would just make more sense?
Typically in code I favor readability over performance and minimalism. Instead of using one RemoteFunction, I would delegate different tasks to different functions. One of the biggest reasons for this is because firing the same event repeatedly in a high-player environment can lead to a poorer player experience, and poorer performance overall. Firing multiple events in a short span of time is more performant and easier to work with.
It’s generally more efficient to use multiple remote events and functions. An empty remote event has an overhead of 9 bytes, and it normally costs much more to send the “case” then having a dedicated remote signal. Strings consume quite some data.
Perhaps if identifier keys were very compressed and consisted of numbers/binaries, one could send data more efficiently, but it shouldn’t be necessary. Most games use multiple remote events/functions, or modules to handle them, but still with multiple signal instances.
Just do whatever is intuitive and easy for you to manage.
The “most efficient” solution in terms of network usage with many events per frame would be to queue requests until the end of the frame and pack them into a single binary string that you send over, but this is complex to implement and not worth doing for most people. Another way is to use string.pack and include the operation as a single byte at the beginning of the string; This makes the width of the identifier/op negligible, and lets you specify how wide you need the data to be.
Lua treats binary strings as sequences of bytes, and doesn’t interpret and manipulate them as characters. So they’re a great choice for sending minimal info. And string.pack packs into a binary form.
@Tomarty that’s it! I knew I read your post somewhere once but didn’t find it until now! I’m glad you responded.