I’m enabling bInterpMovement in the constructor, setting the InterpolatedComponent to an Root Component attached Mesh in BeginPlay. I’m calling MoveInterpolationTarget(LocRoot, RotRoot) on PostNetReceiveLocationAndRotation(). But no matter which values I use, the movement is still choppy and it seems like the interpolation has no effect. Also it seems like (bInterpolationComplete) is always true.
This is an old thread, but I stumpled upon this too. What I found as solution is, you should not set ReplicatingMovement to true and not use PostReceiveNetUpdate (The comments of the interpolation parameters can be read that you should use them).
Instead make you own Location and Rotation replicated properties and in OnRep of these you can call the MoveInterpolationTarget() function, then it should work.
But still, the projectiles are glitching around a bit, not choppy, but they teleport to a complete off location for a frame sometimes. I think I will override the interpolation method to use a simple interpolation on my own.
I met the same proble, is there any progress?
I found that you can use ReplicateMovement with interpolation, but you do have to override PostNetReceiveLocationAndRotation in c++. Instead of calling Super::PostNetReceiveLocationAndRotation() in the override, I copied the code from the actor class, and then inserted the call to ProjectileMovement->MoveInterpolationTarget before it sets the actor’s location and rotation to the replicated data. This way, the actor is still in the old location when you run MoveInterpolationTarget and it can move the UpdatedComponent ahead.
That made the interpolation actually function, but I was still getting jitters. I think this is because there is nothing stopping the PMC from trying to continue with its previous projectile path in the new location set by MoveInterpolationTarget. The UpdatedComponent will snap to a new location, but since none of the projectile logic in the PMC is replicated, the velocity is unchanged, and it tries to continue along its old trajectory. My fix was to set bSimulationEnabled to false on simulated proxies, so that movement on simulated proxies is purely governed by the replicated movement from the server and interpolation.
Like @RaiderOfLostBit said, you can probably just replicate your own location and rotation and call MoveInterpolationTarget from the RepNotify if you don’t want to dive into the c++, but I thought maybe this is what Epic was thinking when they wrote the comments to MoveInterpolatedComponent().