Track sent components for each entity #604
                
     Open
            
            
          
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
Objective
We'll need this for per-component visibility, but this change is useful on its own because it fixes replication for rules with multiple components that were inserted on different ticks.
For example, you have a replication rule for
(A, B). You spawn an entity withA, and on the next tick you insertB. Without this change,Bis replicated, butAis wrongly considered as sent. I added a test for it.Implementation details
Inside
ClientTicks, we now store aHashSet<ComponentId>for each entity in addition to ticks. To make it look nicer, I wrapped them in anEntityTicksstruct. I also renamedmutationstoentitiesbecause it fits better (it's not only for mutation ticks - it's also updated on insertions and removals). To avoid double hashing formutations, I switched to using the entry API and made the field mutable. Because of this change, I also had to remove theis_new_for_clienthelper (in one place I need entry API and in another it's a simplecontainscheck). I adjusted the doc comment and with the new naming it should still be clear.MutateInfonow stores aVec<ComponentId>for each entity, and I update the acknowledged components insideEntityTicks.During removals, we now need to remove components from the acknowledged lists, so I adjusted the logic similarly to how we collect changes.