Open rj00a opened 1 year ago
Add a new component for entities called
MovementUpdateDelay(pub u32)
which defaults to0
. To check if it's time to send movement packets, docurrent_tick % (movement_update_delay + 1) == 0
.The
OldPosition
for entities will change to be the last synced position rather than the position from the previous tick. (Might be better to make a separate component for this, but I haven't thought about it enough).
Wouldn't it be better to just do this method every x ticks ?
As well as the one that update the old position.
We can't just run that whole system every X ticks because there are some things unrelated to movement in there. I also think it would be best to configure this per-entity because I can imagine a server wanting player entities to have as little latency as possible, but all other entities with higher intervals.
I'm looking through Vanilla's and Minestom's source code right now, but I'm having trouble identifying exactly where all this is happening. So I might be completely misinformed.
Describe the problem related to your feature request.
The vanilla server does not send entity update packets every tick. It intentionally spaces them out to reduce network activity. I don't know what the exact number is off the top of my head, but it's something like every third tick. (I suspect this is why entities can feel laggy in vanilla).
It could be useful if valence also had this feature for situations with lots of entities.
What solution would you like?
Add a new component for entities called
MovementUpdateDelay(pub u32)
which defaults to0
. To check if it's time to send movement packets, docurrent_tick % (movement_update_delay + 1) == 0
.The
OldPosition
for entities will change to be the last synced position rather than the position from the previous tick. (Might be better to make a separate component for this, but I haven't thought about it enough).What alternative(s) have you considered?
We could just not do this. The additional complexity and potential bugs might not be worth it.