I’m moving an Actor using the “VInterp to Constant” blueprint node to get the destination position. I can see that the exact vector (400, 300, 200) is being sent to SetActorLocation. Afterwards, I call GetActorLocation and the position doesn’t match.
This doesn’t seem to be a location caching issue or race condition with GetActorLocation, because the actor’s location stays at that incorrect value forever and can be verified in the world outliner.
Setting the actor to that position using a single call will put it in the correct location. The problem seems to be related to rapid updates
The actor is empty so it shouldn’t be related to collision or physics
Sweep/Teleport settings don’t seem to affect it
SetActorLocation’s return value is never false during this test
The location can end up more than 2cm off, which is a noticeable problem for my use-case.
I would guess it is because the smoothing the algorithm has makes such small changes towards the end of it that the changes will be too small to move the actor. As such using this function will not yield the results at the kind of accuracy you want.
You could use a timeline or a curve with a float value that goes from 0 to 1, and lerp from the initial location vector to the target location vector. That way you could also use your own smoothing by easing the curve.
Use the snipping tool to take images of blueprints or use some online blueprint pasting tool to showcase the blueprints, rather than copying the blueprint nodes as a file.
Based on the print outputs I have in there, the problem isn’t related to VInterp. The value coming out of VInterp (and being passed to SetActorLocation) is exactly what I expect. But for some reason the actor doesn’t end up moving to that location.
Your problem is being caused by the fact that a pure Blueprint node is executed every time its output is used.
Pure blueprint nodes are nodes that don’t have an execute pin. Since they don’t have an execute pin, they execute every time their output values are “read from.” Their outputs are not stored anywhere unless you do so yourself. Let’s take a look at why that’s an issue in your situation.
Your pasted blueprint example shows that you have the following sequence of nodes set up (I’m omitting some unimportant stuff to make things clearer):
Set Actor Location. The new actor location uses the output of VInterpToConstant, which takes the actor’s current location and interpolates it a bit toward current target point. So far, so good.
Branch Node comparing current target point to the output of VInterpToConstant. We have a problem here because the output of VInterpToConstant this time is NOT the same as the output it gave during step 1. This is because the function’s input has changed, because the actor has already been moved — the GetActorLocation that feeds into the VInterpToConstant is now returning the actor’s updated location, so naturally the output will be different too.
Print String which prints the output of VInterpToConstant. This output will match the output from step 2, but this call is wasteful because it is recalculating the interpolation — it is not simply returning a stored value.
Print String again, this time printing the actor’s current location. Your comment states “this does not match current target point” and that is absolutely correct. (I’ll explain more ahead.)
The way you have it set up, steps 3 and 4 don’t execute unless the condition for the branch in step 2 is true. At first glance, it looks like that step 2 condition is asking, “Has the actor been moved to the target location?” But that’s not actually what’s going on. Because the VInterpToConstant node is re-evaluated every time its output is used, that condition actually becomes true when the actor is almost at the target location. That condition actually represents the question, “Will the actor be at the destination after one more interpolation?” and everything that follows makes sense when you see it that way.
The solution here is, call VInterpToConstantjust once and save its output as a variable. Call it “interpolated location” or something. Then just read that “interpolated location” variable downstream anywhere you need to compare locations or print out your debug data, etc.
This issue bites a lot of people, and has bitten me more times than I can remember. It’s just something we all have to keep in mind when working with blueprints!