Would it be a good idea to fire a remote event rapidly, say, every .5 seconds? I heard that the clients might encounter Latency issues, however I’m not too sure.
Thank you.
No, that’ll cause remote queue exhaustion and depending on what the event does on the server, server lag.
An example of how you can prevent remote event queue exhaustion: If you’re scripting guns, you can fire the server when you press down and fire it when you stop pressing down instead of firing the remote at every shot fired, by doing that instead of firing it at every shot fired you can minimize the amount of remote traffic by a lot.
5 Likes
You should always look as keeping the network traffic to a minimum. There is a limit to the amount of network allocated to each client.
4 Likes
Another thing is, firing a remote way too often will pointlessly consume your players’ bandwidth. It obviously depends on how much data you pass, but in general it isn’t a good idea.
1 Like
I see, thank you.
I’m currently trying to make a feature for my game which shows the amount of people in the certain place on a TextLabel, that’s also controlled by a server script, e.g:
while wait(.5) do
for i, v in pairs(game.Players:GetChildren()) do
v.Character:FindFirstChild("Event"):FireClient(v, NumValue)
end
end
Changing the text for every player, simply wouldn’t work because server scripts do not have access to PlayerGui’s. What I had in my mind was to use FireClient every .5 seconds for clients, which I know is a horrible idea, but I don’t have any other ideas. Would appreciate your suggestions on how to go around this.
Remote’s have their events cached/buffered and processed at a fixed rate, so if you managed to fire a remote event 100 times in a single frame then they would be queued up and batch processed on the next network tick. The number of events you send doesn’t really matter, what matters is the overall bandwidth you are using. The wiki claims you should use a max bandwidth of 50 KB/s (Documentation - Roblox Creator Hub) and I would advice you try to stick to this, although in my experience servers can handle far more. You bandwidth usage can be found by using the developer console ingame.
While the number of requests will increase the bandwidth you use (as there is some overhead per request) you can fire way more than you may initially expect. There also doesn’t seem to be any performance hit from using many requests other than more bandwidth, but as long as the bandwidth is under control you shouldn’t have any issues.
Do note that the queue/buffer does have a fixed size. I’m not sure what the size constraint is but you may hit it (and cause a queue exhaustion error) if you manage to fire 1000’s of requests in a single frame for some reason. I have not managed to hit it without saturating the bandwidth to the server though.
tl;dr Fire as many remote events as you want, just watch your overall bandwidth usage.
23 Likes
Why do you need to fire the client to do that? You should be able to get the players in the area and update it all on the server (unless the textlabel is in a screengui and not a bilboard ui)
That’s the problem here - it’s a PlayerGui I’m trying to access through a Server Script every x seconds. And by the Area I meant a Table.
Instead of firing every half a second, why don’t you just fire the client whenever a new player joins? Also, you can use FireAllClients() instead of FireClient if you want to update every client.
3 Likes
you can do this right in the localscript since the same information is readily available to the client as well
3 Likes
Firing a remote two times a second will not exhaust the queue if both sides are connected to the event.
There are perfectly fine use cases for firing a remote a few times per second, such as informing the server about character state.
3 Likes
Doesn’t quite answer my question since the Table is updated whenever someone does a certain action. So as soon as the table updates I want the server script to update the players’ textlabel showing how many people are in this table. I did try to fire the event when this table is updated(When something has been inserted or removed), however it might get pretty messy since I’ll have to deal with metamethods and etc.
Hold on. What exactly is your use case? What are you doing that supposedly needs a remote to go off this quickly? I’m sure there’s a better way to do this.
I’m sure there is another way, but I’m really confused at the moment. I think I’ve mentioned what I need above. What I want to do is for the ServerScript to sort of inform the players about how many of them are under a certain Tag.
I assumed he was referring to firing the server in the original post. If your game has a lot of players and you rapidly fire the server, that won’t cause remote event exhaustion and/or a lot of server traffic?
1 Like
I’ve used remotes before where I fire the server 2-5x per second to inform the server about character state (such as look angle) and this will never be the main source of bad server performance, nor event queue exhaustion.
3 Likes
I don’t get it. Please be explicit. What are you trying to do? What is all this about “tags” and whatnot?
There’s a ServerScript which has to inform the players through their GUIs about how many of them have the BoolValue - Tag, in total set as True.
People on Roblox often think using the network routinely to be a bad thing. This simply isn’t the case. It’s completely valid to fire a remote over quite a few times a second. The bandwith cost is mostly going to be in the content you’re sending over, so that’s the bottleneck to look out for. There’s no issue with sending traffic over the network upon every network tick when it’s called for.
16 Likes
No need for metatables, simply add an API to set whatever value it is you are concerned with, and have that function inform all clients that this happened.
local function set_special_value(new_value)
-- set value
-- inform clients
end