Hi all,
What I’m trying to do is when the player steps inside of a trigger box, it moves a blocking volume behind them so that the player cannot retrace their steps. This is what I have so far:
When the player enters the volume the SetActorRelativeLocation is called but the volume doesn’t move. Why is this happening? Am I missing something?
Thanks for any and all help!
I may be totally wrong, but I think the “SetActorRelativeLocation” only applies to components inside of your blueprint? Because they’re moving relative to the blueprint origin. You’re trying to move an actor relative to an origin which doesn’t exist because its not in a blueprint.
I’d try using “SetActorWorldLocation” instead and use the “GetActorLocation” node and add your offset to it and feed the result into the “SetActorWorldLocation” vector input value.
Thanks! I was using the Level Blueprint to do this so as you said the components weren’t inside the blueprint to begin with. One question though, how do you know where the blueprints origin is? Is it at world 0 or the combined positions of all of the blueprint objects?
The origin is always at the coordinate [0,0,0].
So, you’ve got a bunch of different coordinate systems you have to deal with, right? There’s the world space coordinates, which has an origin at [0,0,0] in world space. Then there’s the object space coordinate system, where an object has its own origin, also at [0,0,0]. Then there’s a few other coordinate systems which the engine takes care of for us (perspective and projection matrices).
You’ve also got “model” space coordinates, where a static mesh is placed relative to an origin as well, but this is done within a modeling program such as Maya.
It’s easiest to understand these different object spaces by looking at a few different vertex positions in 3D space. Ultimately, everything gets boiled down into vertices in the graphics card and the rendering pipeline ultimately just gets one vertex position in screen space (flat X/Y coordinates on your screen).
So, let’s pretend we’re creating a super simple static mesh to represent a sphere. Let’s imagine that we’re doing this programmatically so we don’t have to monkey around with a modeling program. The sphere radius is arbitrary, so let’s pick 100. The center of the sphere is at [0,0,0]. Knowing this, we can say that the farthest X coordinate of the sphere would be [100,0,0]. The sphere is centered at the objects origin. Now, let’s say that we do a translation to the right on the X axis by 50 units. The center of the sphere is now at [50,0,0], and the farthest X coordinate is at [150,0,0]. The origin is still at [0,0,0]. If we do a rotation of the sphere, the rotation is always relative to the origin. Internally, the engine can do multiple rotations and translations, so even if you translate an object from its origin, you can still rotate it in its own local space as if it were centered at the origin. Anyways, all of these coordinates are in this spheres LOCAL space.
Let’s say that we now take this sphere, put it into a blueprint, and drop it into our game world. The sphere blueprint now has a world transform matrix representing its position in world space as well. Let’s say that we placed the sphere blueprint at the world space coordinate [500,500,500]. Where is our actual sphere located in world space?
We take the world space coordinate [500,500,500] and we add the sphere’s local space offset coordinate [150,0,0], and we get a final result of [650,500,500]. Now, we can do two types of translations: We can move the object in world space, or we can move the sphere component in its local space. If we move the object in its local space, we’re moving relative to its own origin, which is centered in world space at [500,500,500]. So, we could have our sphere orbiting around its local origin [0,0,0] and in world space, it would be orbiting around the world coordinate [500,500,500].
The important thing to note is that all coordinate systems are relative to the parent. If you imagine our solar system and all of the objects contained within it, you could say that the sun is the parent for all of the planets. The planets all move relative to the sun. Some planets have moons which orbit the planets. Those moons move relative to the planet position. Those moons may have satellites orbiting them, so those satellite orbit positions would be a relative offset from their moon. So, when you look at your scene graph in blueprints, everything is relative to its parent, much like planets are 
Lol, thanks for the detailed response! I already knew about a few of the different origins (or coordinates) that are inside UE4 when using them but this pretty much covers everything :D.
