Currently if you have a member that is replicated at an interval a message is sent every time the interval is up even if the value has not changed. For instance if you got an interpolated vector2 for a player that goes afk network updates will still be sent even if that player is not moving.
Suggestion
We could introduce logic that stops sending a member after it has had the same value for X update cycles. Even if this is an interpolated vector2 the receiver can still estimate where to interpolate from since they also know the frame window. So they can just interpolate as if they received an update with the last known value the last frame window before the current update.
Example
Imagine the frame window for interval is send every 6 frames and the client receives the following packets.
Tick 100: Vector2(10, 10)
Tick 106: Vector2(10, 15)
Tick 112: Vector2(10, 20)
Tick 118: Vector2(10, 20)
Tick 124: Vector2(10, 20)
At this point movement has stopped for a while then later on the client gets an update like
Tick 412: Vector2(10, 25)
At this point the client can just calculate that at tick 406 (412 - 6) the Vector2 should be the same as it was at tick 124. As it got no updates inbetween. Of course this might be wrong if some packets have been dropped but it would quickly correct itself as new packets come in.
Potential issue
For new clients that join if they do not receive the intial update during synchronization they may not get any updates for a long time if the value does not change. As such it may be worth considering changing initial synchronization to always be reliable. At least if this this mode is active.
Currently if you have a member that is replicated at an interval a message is sent every time the interval is up even if the value has not changed. For instance if you got an interpolated vector2 for a player that goes afk network updates will still be sent even if that player is not moving.
Suggestion
We could introduce logic that stops sending a member after it has had the same value for X update cycles. Even if this is an interpolated vector2 the receiver can still estimate where to interpolate from since they also know the frame window. So they can just interpolate as if they received an update with the last known value the last frame window before the current update.
Example Imagine the frame window for interval is send every 6 frames and the client receives the following packets.
At this point movement has stopped for a while then later on the client gets an update like
At this point the client can just calculate that at tick 406 (412 - 6) the Vector2 should be the same as it was at tick 124. As it got no updates inbetween. Of course this might be wrong if some packets have been dropped but it would quickly correct itself as new packets come in.
Potential issue
For new clients that join if they do not receive the intial update during synchronization they may not get any updates for a long time if the value does not change. As such it may be worth considering changing initial synchronization to always be reliable. At least if this this mode is active.