If the server sends updates every 20ms and an entity is updated every 10ms. Then the entity will only get updated every 20ms right? There’s no way to be faster than the server send-update rate.
If the server sends updates every 20ms and an entity is updated every 30ms; how does it work? Does the entity have an internal timer that starts everytime the server sends packets, so in practice the entity will get replicated every 40ms? i.e. is an entity’s actual update-rate always a multiple of the general server-wide update-rate?
If the server sends updates every 20ms and an entity is updated every 10ms. Then the entity will only get updated every 20ms right?
Right! The sender maintains a buffer that aggregates all changes. Those are flushed to the network at send frequency. In other words, if our 10ms interval entity sets position to (10, 10, 10) in the first update, and then to (20, 20, 20) in the next one, it is only the last value that will be sent, i.e. (20, 20, 20).
If the server sends updates every 20ms and an entity is updated every 30ms; how does it work?
Every binding has its own sampling clock, meaning that in case presented it would get sent 2 times in a span of 60ms:
10ms
20ms
30ms
40ms
50ms
60ms
Sampled
Sampled
NetFlush
NetFlush
NetFlush
Note: I’m assuming that by “updated every 30ms” you mean that its sampling rate is set to 33Hz. Keep in mind that if the value of the binding doesn’t change then we’re not sending anything.
I notice that there is also a per-field sample rate even for a single binding.
That means that it’s not guaranteed that the binding’s state on the receiver is the same as on the sender at a past tick?
i.e. the position could get sampled and sent, but the rotation wasn’t?
This feature is the cornerstone of bandwidth optimization. In most games only few properties require frequent updates (usually position) while others can be synced as infrequently as once per second.
This let’s you sync far more entities than in the traditional snapshot approach.
