I have a blueprint that says if player overlaps with a collision sphere, a component from that blueprint (An object and a collision cube inside it) has its location set and should be teleported elsewhere. But the object stays where it started and it doesn´t go to the location it should, even though the rest of the commands work properly.
Any ideas on whats the problem and how to fix it?
Hi!
One thing I’d check is the actor reference you’re using in your OnActorBeginOverlap event.
The event has two actor outputs:
Overlapped Actor: the actor whose overlap event is firing, usually the actor containing the trigger.
Other Actor: the actor entering the overlap, in your case presumably the player.
If you’re checking for the player or using the overlapping actor to drive your logic, make sure you’re using the correct reference. You can connect Other Actor
If you’ve already doing this, could you share the actual Blueprint logic that’s supposed to move the object, including the location setting nodes? The screenshot of the overlap logic helps, but seeing the full chain would let us diagnose the problem more precisely.
DorrealArt’s check on Other Actor is the right first step. If the overlap path is already correct and the rest of the chain still runs, the usual reason Set World / Set Relative Location “does nothing” is that the component is not free to move.
Check these in order:
Mobility – Select the mesh + collision cube you are teleporting. In Details → Transform, Mobility must be Movable. If it is Static (or the parent actor is Static), the set-location call is ignored at runtime even though the Blueprint compiles and the rest of the graph fires.
Relative vs world – If that component is still attached to the actor root (default), Set World Location moves it in world space for one frame, then the attachment can snap it back relative to the root on the next tick. Prefer either:
Set Relative Location with an offset written in the parent’s local space, orSet Actor Location if both the mesh and the cube should stay together.Physics – If Simulate Physics is on for the mesh or the cube, Set … Location fights the physics body. Either turn Simulate Physics off for the teleport, or use Set World Location on the primitive with Teleport / SetAllPhysicsPosition / disable simulation for a frame.
What you are actually moving – Make sure the target pin is the component you think it is (the child mesh/cube), not a different instance. Print Get World Location before and after the set on that same component reference; if the printed value never changes, the pin is wrong or Mobility/physics is blocking it.
Collision cube inside a mesh component – Nested components inherit the parent’s transform. Moving only the outer mesh and expecting the cube (if it is a separate component) to follow only works if the cube is a child of that mesh. If both are siblings under the root, move both, or parent the cube under the mesh.
Quick test: temporarily call Set Actor Location on self to a known spot in the same event. If the actor jumps but the child still does not, it is almost certainly Mobility, attachment, or physics on that child.
I checked all of these and they seem to be right. I tried the quick test too but neither the actor nor the component moved. Then I tried moving the player in that same event and it acted like he was being moved to the component and overlapping with its trigger, event though I was moving him to the other side of the map, so I´m very confused.
Anyway, here´s a screenshot from the blueprint.
I tried reproducing your setup in a test level, and your logic works correctly on my end. I also experimented with different component hierarchies, including changing the Default Scene Root, but the component still moves as expected.
Try adding these Print String nodes shown below to verify that the character cast succeeds and that execution reaches the Branch and the location-setting node. So far, I haven’t found an issue with that logic.
If all checks out and it still doesn’t move, another possibility worth investigating is whether another piece of logic in your project is setting the component’s location elsewhere. I was able to reproduce a similar symptom by having a second piece of logic override the location on the event tick.
To check this, try printing the component’s world location immediately after Set World Location and Rotation. If it reports the new coordinates, but the component remains in its original position or returns there afterward, something else may be changing its transform. You could also search your Blueprints for other nodes that modify the location of this component or its parent.
If the printed location never changes, then we’ll need to investigate further, but at least this should help eliminate the second logic possibility.
The first print string after casting to player printed: TP cast check TP cast check TP cast check. So the cast didn´t fail, but it printed 3 times for some reason.
The second one after the branch printed 3 times too and it said: false false true. But that variable should start unchecked, and the rest of the branch is executed, so I don´t know why it would be false…
The third one printed the correct location where the component should be teleported to, but when I go to that location, I can´t see him there and his collision box doesn´t trigger anything when the player should be touching it. So I don´t know what´s going on.
The unexpected Boolean values strengthen the suspicion that something else in your Blueprint might be interfering with the logic.
To see if the boolean check causes the problem, bypass the “Croc Chase” Branch temporarily and connect casting directly to “Set World Location and Rotation”.
If that changes nothing, keep printing the world location of the component immediately after “Set World Location and Rotation”, then again after a “Delay” of 1 second.
If the location changes between those two checks, something is modifying its transform afterward. It could be another piece of logic triggered when “Croc Chase” becomes true, for example.
If thats the case, you should find what else has a reference to crocs or this blueprint and try disconnecting one at a time to find the culprit.
If you can’t identify the cause, I’d try creating a completely fresh Actor Blueprint that isn’t referenced by any other logic. Give it just the trigger, the static mesh, and the movement logic we’ve discussed. Test that in an otherwise empty level.
