The interpolation target is used on clients in combination with the source to interpolate from the old value to the new. The owner, however, does not need it, as it is the authority on what the values are in the first place.
When ownership later changes to another object, the original owner will also start interpolating, as expected, and will also call SnapInterpolations to ensure all interpolation immediately resolves to its target.
This is fine, but the owner never seems to keep track of the target interpolation in the first place, as it's only read by others. This causes the owner to snap to the values it had from before it became owner (or the default values if it was the first owner). After snapping, it would then start interpolating from the outdated value to the new target sent by the new owner, and "correct" itself from there on out.
In the case of e.g. a scale that is applied, this could result in a noticeable visual "glitch" where the owner would see the object shrink back to its initial value, then grow very quickly to the size it was, and then start interpolating. In other words:
Have a network contract that updates a Float3 of Vector3 scale using the transform as in a typical case, in the same way as the moving cube example, but for scale.
Add functionality to allow another client to claim ownership so it can dictate the scale.
Connect using two clients to the server.
Spawn the cube using one client A with the default scale (1, 1, 1).
Make it very large on the owner client A.
Take over scaling in the other client B and try to make it even larger.
Observe on the original client A that the cube will first "jump back" to the original scale from 4, then quickly jump to the scale it was supposed to have in 5, and then start growing due to interpolation as B rescales in 6. On client B, no such behavior is observed (as it is now the owner and the authority on the changes).
This fixes that by also keeping the target around on the owner, where it can then be used in that corner case.
Possibly fixes #220. Needs a manual regenerate or update of existing network objects to actually do anything.
The interpolation target is used on clients in combination with the source to interpolate from the old value to the new. The owner, however, does not need it, as it is the authority on what the values are in the first place.
When ownership later changes to another object, the original owner will also start interpolating, as expected, and will also call
SnapInterpolationsto ensure all interpolation immediately resolves to its target.This is fine, but the owner never seems to keep track of the target interpolation in the first place, as it's only read by others. This causes the owner to snap to the values it had from before it became owner (or the default values if it was the first owner). After snapping, it would then start interpolating from the outdated value to the new target sent by the new owner, and "correct" itself from there on out.
In the case of e.g. a scale that is applied, this could result in a noticeable visual "glitch" where the owner would see the object shrink back to its initial value, then grow very quickly to the size it was, and then start interpolating. In other words:
Float3ofVector3scale using the transform as in a typical case, in the same way as the moving cube example, but for scale.(1, 1, 1).This fixes that by also keeping the target around on the owner, where it can then be used in that corner case.
Possibly fixes #220. Needs a manual regenerate or update of existing network objects to actually do anything.