Fix issues with DeltaCompression
cBournhonesque opened this issue · 0 comments
- DeltaCompression does not work if you have multiple replicated components on the entity, because we keep track of the
ack_tick
per replication_group; so the sender could receive an updated ack for that replication_group, but actually another component got acked
Solution: We need to keep track of the ack_tick
per component/entity
- Similarly, the receiver could receive/process at the same time for the same replication group 2 updates for the delta-component; one for tick 7 and one for tick 10.
We just take the latest one and apply the tick 10 one, and we ignore the tick 7 one (because we only apply the most recently received update) -> sequential receiver.
However the sender thinks that tick 7 was received since it received an ack and sends diff from tick 7, that the receiver isn't able to compute.
One solution for this would be to read all updates, not the just the most recent one for the ReplicationGroup.
(we don't need to actually apply it, we just need to store it in the ConfirmedDeltaComponentHistory
)
-
Looks like we can receive 2 ack_ticks at the same time; in this case we need to keep using the last one!
-
It looks like the send delta-manager kept an older version of the component even though we acked a more recent version?
-> that's because we only get rid of the data when all clients have acked at least this tick. -
Sometimes it seems like the receiver doesn't have the data in its ComponentHistory even though it should! Is it because the ack receival doesn't work? or the receiver somehow doesn't store the data?