Skip to content
This repository has been archived by the owner on Aug 15, 2022. It is now read-only.

Fix interpolation starting from incorrect source when disowned #391

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

NoTuxNoBux
Copy link

@NoTuxNoBux NoTuxNoBux commented Dec 2, 2020

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:

  1. 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.
  2. Add functionality to allow another client to claim ownership so it can dictate the scale.
  3. Connect using two clients to the server.
  4. Spawn the cube using one client A with the default scale (1, 1, 1).
  5. Make it very large on the owner client A.
  6. Take over scaling in the other client B and try to make it even larger.
  7. 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 the owner later on 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 kept 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).

This fixes that by also keeping the target around on the owner, where it
can then be  used in that corner case.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant