Which method for remotes would be most appropriate? Single remote or Multiple (2-3)

So currently I have code where it fires players data in the forms of multiple tables like so:

--from server
PlayerDataRemote:FireClient(PlayerStats, Inventory, Equipped)

and the question is, would it be more appropriate to separate each into multiple remotes as I plan to have the inventory system receive the event (although playerstats is not needed), shop to receive player stats (like money and/or levels) level gui to display current level (player’s stats)

all versus having 1 remote and obtaining all the necessary data and extra data.

The above would be fired when updated, round ends get coins xp level up maybe, buy from shop you deduct cash and now own the item)

What are your thoughts?

3 Likes

It depends. If you’re just firing from the server to the client and the client receives everything to set everything up, you’re probably fine with one remote.

The only reason I can think to have multiple remotes is if the client needs different things in different functions/scripts if that makes sense. If you have one script handling the PlayerStats, one handling Inventory and a third one handling Equipped, you should use multiple.

1 Like

I was just wondering because theres no topics about firing a remote and then having multiple onclientevent receiving functions–since many of the tables used are interlinked in functionalities with the systems

1 Like

Honestly it really depends on how you want to go about doing it since your case is kind of special. If I were you, I would have one listener on the client to initialize the client. Then inside of this listener, initialize the client however you want but possibly create multiple threads. This wouldn’t be an issue as each variable defined in the listener is within the scope of each of these threads.

But honestly if you decide to use multiple remotes, the most important thing is that as long as it works for you, it shouldn’t be an issue.

I prefer multiple remotes for the sake of clarity and so that one argument isn’t responsible for deciding all the different kinds of overloads that the code needs to track. As far as I know, all network traffic logically still files through the same line, just which events get fired change based on the incoming information.

1 Like