Bug Ghost component does not trigger change filter when write the same data

Hey optimise. If I understand you correctly, this is a limitation of netcode.

1. We can't (efficiently) record every change version bump for every single ghost chunk, per component, on the server. Tracking this would be costly in both CPU cost, and bandwidth cost.
2. Thus, the algorithm netcode uses on the client is: Detect a change in component value (from the server), then only bump change version for that chunk if the value was actually modified.

I.e. We expected users to mostly want to know when ghosts on the clients were updated with a changed value. We can't track false positive writes.

 

Thus, given that expectation, the previous implementation we had was more correct, because you actually pretend there are changes all the time. What you are asking is probagating the information that the server touched a component to the client. That can be possible, but requires a complete different concept (you just want to know if the server wrote on a component). Or better, you just expect that as soon as new data from server this actually change the value, because that is what you are asking.

 

Correct, your approach is the only way to get updates about the server writing to this component but without actually modifying any GhostField values. FWIW: It'll be delta compressed extremely well.

Note that due to our network model being "eventual consistency", there is a chance that:

1. Server bumps the value.
2. Client does not receive (due to other ghosts having higher importance).
3. Server bumps the value again.
4. Client receives an update where the version was bumped twice.

This would be almost identical to what you're currently doing via a BumpVersion byte, so no, unfortunately I wouldn't expect us to support this via a new API.

Note that - before change filtering was applied - netcode would report that a GhostField component changed every single Simulation step. Therefore, using [GhostField] byte BumpVersion (along with the new change filtering fix) should lead to better filtering than you had previously (at the cost of a small amount of bandwidth).

 

For buffers, if the count change, we consider the buffer changed. Otherwise, if any of the element inside is changed, we consider the buffer has changed.