I’m currently firing 1 remote per .1 seconds (10 remotes per second, 200 per second total for a full server) in order to accurately let the server know the other players camera CFrame so I can move other players heads / arms on each others clients. Anything slower than .1 seconds seems choppy (even .2 seconds), is this acceptable performance wise?
Edit: I can do it in around 100 remotes per second if I set the easing style to linear but I’m still not sure if that’s viable.
yeah I think its fine performance wise, I checked and updated humanoid moveto() at least 100 times per 1/30 seconds in the past and it didnt hurt performance, so I guess 20 every 0.1 seconds would be fine
Performance isn’t an issue with the rate you’re giving me, so it’s fine. Even per 0.05 seconds work fine with no performance issues
Yeah I haven’t done performance tests and I’m not too sure how to reliably check performance when doing so. I’ve decided that with a linear easing style I can bring it down to every .2 seconds but anything higher and my tweens are choppy.
Oh wow, I thought Roblox wasn’t optimized enough to handle remotes being spammed that often, do you know if there’s an upper limit to which you can spam remotes before preformance takes a hit? Is it like (1000 remotes per second) upper limit or something?
There is a point where remote events can be exhausted and dropped, but it’s only by some people who spam them every task.wait() with a while loop or a repeat until loop. Roblox is surprisingly good at handling asynchronical connections despite how unoptimized their hardware is.
P.S. People with lag may have trouble connecting to the server endpoint, so it may delay for them.
If you’re really concerned about it being too much, I’d recommend trying Unreliable remote events. If you know what TCP/UDP is it’ll be easier to understand, but otherwise…
If you’re trying to send a file over the internet, if any of the sent data is lost it will be re-sent (TCP). This means you won’t lose any data, but it might take extra time to have it be sent back again since both sides have to confirm the data was lost and must communicate to have it re-sent.
If you’re trying to watch or stream a TV show, you won’t care if you get every single frame. It’d be more annoying for the show to pause every few seconds than to lose a few frames every now and then, so if any data is lost, it is dropped and isn’t re-sent (UDP). This is a much faster process with less delay, but should only be used in cases where transmission speed is valued over getting all data.
Similarly, with normal remote events, if a remote doesn’t reach the other side it will be sent again to prevent it from being lost entirely. However, this re-sending can be time consuming and can cause remotes to lag behind.
Unreliable remote events solve that issue; rather than having to be re-sent, they will be dropped entirely, meaning there will be minimal lag between remote events since the system won’t have to backtrack to ensure all data is sent. If every single remote event is important, I wouldn’t recommend doing it, but if you can afford to drop one or two remotes every few seconds then this should be faster.
Alright sounds good, looked into it and I’ll be using the unreliable events for info like updating my camera info server side.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.