So when telling client changes of some stats I only want to send them once per actual network replication exchange(? idk terminology)
I know that it runs at 30hz20 hz
Reasoning for why I want to do it once is because remotes aren’t guaranteed to preserve order and I don’t want outdated stats being sent first last (so being the ones the receiving end believes is the newest) etc
Also its cool so yea even if you can come up with a reason for why I dont need to call right before network replication (please share how if you do though) I still want to know how
Maybe this is part of the solution? In this post it says directly after renderstepped on every other frame it network replicates? So all we need is to know which is the specific frame that it replicates on and then update stats on every other one after it while in render stepped?
Specific code would greatly be appreciated for this for BOTH client and server (although server might be tougher since it doesnt render anything - but would that mean its directly after heartbeat / is this even possible on server lol)??
orrrr is this completely hopeless and do I need to use objectvalues until this feature is added?
Theres still a communication delay and stuff could happen in it
Yea all I could think of for now too is UI but idk its a nice thing to have
I think I’ve experienced situations where they don’t go in order though and also I’ll find some posts about it really quickly too since I was just searching it
I can’t think of a healthy use case of sending data down a Remote at 30Hz.
Perhaps rethink your network strategy? I’d really recommend sending as little data as possible, and in as few increments as possible. That doesn’t mean compacting, it means that you should rarely send any data you don’t vitally need.
I don’t know what type of game you’re making, but again, it is very bad network practice to send frequent requests to a RemoteEvent. You’re going to be hitting networking limits pretty quickly.
The timing of when you fire a remote event should be irrelevant. Network latency will mean any effort you put into timing it will be significantly outweighed by not just the absolute latency but the variance in it. Your system should be tolerant to variance in timings as well as mis-ordered network events.
A simple way to achieve this would be to just include a (possibly truncated) timestamp.
As for how often you can fire remote events, you can do as much as you want. As long as you don’t saturate the connection there will be no problems. There is some overhead per request so it is advisable to batch data up so each replication cycle you are only sending one request.
The wiki claims a reccomend max bandwidth of 50KB/s (https://wiki.roblox.com/index.php?title=Remote_Functions_%26_Events#Bandwidth) which I find to be significantly lower than what can actually be handled (I’ve manged to hit multiple megabytes a second) but aiming for lower usage is always a good thing, especially when targeting mobile devices.
50KB/s allows for ~1KB per remote event call (50KB/s is both send AND receive). 1,000 bytes is a pretty decent amount of data to be able to transfer every 20th of a second. For example if you wanted to include a timestamp with every request, that is only 8 bytes of 1000 used.
Now be careful of how the remote event buffers work. If you send too much data then the buffers will start filling up and there isn’t a function exposed to us to clear them so old requests will stay creating latency which will keep increasing. This is quite obvious when it happens.
I don’t think you have to worry about remote events arriving out of order.
(AxisAngles corrects the no packet loss thing in another tweet)
It’s anecdotal, but I have an “out of order-intolerant” component in my game which nonetheless works flawlessly with ~500 ping.
Have you actually tested the game to find out that stats are arriving out of order? If you have, are you sure that you’re actually sending it in the right order?
Edit: If these stats just numbers, you can use a NumberValue and listen to the changed event on the client.
I remember a while ago I made this remote event “security” module (which I’m pretty sure someone on the devforum also made and released but got removed because of the fact that the calls are not guaranteed to be in order) which would send a number with as a parameter in the remoteevent and then update the expected number on both the client and the server through some function and everytime the server received the number, it would check if it matches with client’s expected number. I stopped using it for precisely this reason that the packets were arriving out of order and therefore resulting in the server determining the client as cheating
also in his second tweet axis angle says
“well I lied a little. There is packet loss, but lost packets are resent so that there’s no data loss. It just incurs latency”
so doesnt this mean that there is a delay on packets that would have packet loss and hence they arrive out of order?
Ya I think you’re right @Lightlimn I’ll fix my posts
The system is designed so you don’t have to worry about the replication process. It’s handled behind-the-scenes. Things will properly queue up and execute in correct order.
Yeah, I wouldn’t recommend NumberValues or just Value objects in general for replicating stuff since you can throw in more data if you really need to later rather than having to set up a separate system. For example, in my damage replication I send the new health of the entity and the damage amount, element, source etc.
AA said in another tweet that packet loss does occur, but these get resent. Out of order packets don’t even reach the application layer (i.e. Roblox) since this is all handled by TCP.
As for a staff member saying that using ValueObjects as a hack, shrug. People use hacks all the time, and using ValueObjects is waaaay simpler than using remotes for every single stat in your game. I use ValueObjects for map timers, ammo count, health, and a dozen of other stats and it makes managing them a lot easier than having to use Remotes for every single stat.