Change direction of movement of teleported actor

Hello. I want to be able to teleport actor and change its direction of velocity. To explain here is example: If I shoot projectiles through portal they continue flying the same direction I shot them. I can change the rotation of meshes but that doesn’t change the direction of their movement. I want to be able to change the direction of movement, like if I put one portal in opposite direction of another so the projectiles/actors will loop between those portals. Thanks.

There are 3 things you need to deal with in order to make this work:

  1. Change the actor’s rotation to match the delta between the in-portal and out-portal
  2. Change the actor’s location
  3. Change the actor’s velocity so that momentum is conserved

In addition, each portal needs a reference to each other.

What I did is create a new bluescript based on Actor, added a Scene component for the root, and then added a Box Shape that had extents {10,80,160}. In it’s collision, I made sure that “GenerateOverlapEvents” was checked and it was “OverlapAllDynamic”. I then unchecked “HiddenInGame” so I could see it.

In the EventGraph, I created 4 variables

OtherPortal : Actor
HitMe : Actor
ImpactVelocity : Vector3
ImpactRotation : Rotator

I then dragged two instances into the First-Person template and set them up against walls so that their x-axis points away from the wall they are standing against.

I then set the “OtherPortal” reference so that each one pointed to the other (you could actually do this with any number of portals in any order you want). Be careful when doing this, it’s easier to use the drop-down menu in this case or else each one just ends up referencing itself.

Now in the EventGraph, we’re going to do everything off of “EventActorBeginOverlap”.

Step 1 is to change the actor’s rotation - this is done by taking the rotational delta between the actor and the current portal and then combining that with rotational delta between the two portals. We then add 180 degrees to the yaw so that your rotation is “coming out” of the portal instead of “going in.” We also do a few other calculations here that will make things a LOT easier when we get to step 3.

Next, Step 2 is to change the actor’s position. We have to be careful here, though - we want to “push” the actor out of the outgoing portal a certain amount so that our portal-jumper doesn’t activate the portal she just came through and end-up jumping back and forth. We take the forward vector of the “other” portal, multiply it by about 200 and change the actor’s position to that new locations.

Finally, in Step 3, we have to change the velocity of the actor so that she is coming out of the out-going portal just as if she had “gone through” it from behind at the same angle of incidence of the in-going portal. The combination of Step 1 and Step 3 gives the appearance of conserved momentum. Most of the parts of this calculation, though, have already been done in Step 1, so we just reference those variables now. Thankfully, UE has a “rotate vector” function which makes this easy.

The only tricky part is knowing WHAT part of the actor gets this new velocity. What we want to do is to change the velocity of the MovementComponent. To get that, right-click in an open part of the graph and type in “Set Velocity” (with the space and Context Sensitive unchecked) and you’ll find the node you want listed under the “MovementComponent” header. Now we have to work backwards – drag-off the “Target” pin and select “GetMovementComponent” (no spaces, Context Sensitive checked). Now drag-off the “Target” pin from the GetMovementComponent and type in “GetInstigator” and select the one under Actor. Finally, drag out a “get” reference to “HitMe” and wire that up to the “Target” of the Instigator. (Phew!)

That’s pretty much it. Hope that helps!

27616-solution_change_teleported_actor_rotation_3of3.png

Thank you for your great answer. Everything is nice but this will work only for actors with movement component. Is there any way to do it with simple actors like meshes or other blueprint actors?

It would just be a matter of finding the component that is causing your actor to move. Normally, that’s going to be either a MovementComponent or a ProjectileMovementComponent. If you use the ProjectileMovementComponent, then you may have to transform the velocity to the object’s local space before applying it. There was [a post here][1] that describes the two processes in blueprint (not sure if you need it, though, depending on what you are doing).

27796-solution_change_teleported_actor_rotation_4.png

Thank you again. But :)… what about other actors (by “actor” I don’t mean my character, I mean actor in UnrealEngine language - everything placable) like meshes and other things that doesn’t have MovementComponent or ProjectileMovementComponent. Does this mean if an actor doesn’t have MovementComponent or ProjectileMovementComponent or it is not a blueprint actor its velocity can’t be changed?

Sure, you can change the velocity of plain static mesh with no movement components. From what I’ve seen so far, everything that can have a transform and a volume with get both Physics and Collision properties - so you should always be able to use the various “Physics” functions like “SetAllLinearVelocity” – it’s just a bit tricky to get at it.

I’ve modified my example above to demonstrate a portal that (should) be able to teleport anything with a static mesh and a PrimitiveComponent of any shape.

For this example, I’m setting up my “static-mesh-only-Actor” to have a shape component (box in this case) as the root – this will just make it easier on the engine to do physics calculations. It will also allow us to get easy-access changing the location and rotation via the PrimitiveComponent – which allows our portal to work on anything that has any type of PrimitiveComponent. This actor will generate overlap events with any WorldDynamic object type that is also generating overlap events (the static mesh is just for “show”, so it’s physics and collision are turned off).

OK, now for my portal, I’m going to set it up so that it generates overlap events with anything else that is generating overlap events. Notice that if you use “OverlapAllDynamic,” it actually blocks Projectiles. We want overlap events from everything, including projectiles, so we have to use “Custom” and turn on Overlap for Projectiles. Shooting bad guys by shooting them through portals – skill level over 9000!

Alright, now we’re going to have our portal respond to an ActorBeginOverlap event - just like before. Our calculations, though, will be a little different. First, though, we just need to save off a few variables to make our life easier and keep our graph clean. If you look at the way I’m getting the PrimitiveComponent, you’ll notice what looks like an extra cast. It’s not extra, though – it’s needed. It turns out the generic “Get” array function seems to “box up” the type, or perhaps it’s just making it inaccessible to receiving pins??? I’m not sure, but I had to re-cast the type PrimitiveComponent in order to use it. Also notice that the “HitMePrimitiveComponent” variable here is an object reference, not a class.

As a side note, please don’t ask me to explain all the problems with setting an actor velocity after it goes through a hit event. I found all kinds of weird things that happen after hit events occur. It turns out, hit events seem to “turn things off.” I haven’t yet been able to find the documentation that explains exactly what, where, and why. Suffice it to say, changing velocity after hit events is all kinds of craziness – don’t go there. Overlap events are your friends.

OK, now “Fun With Rotators.” This is very similar to what we did before, but we’re just doing all of our critical calculations in one step using the SetWorldLocationAndRotation for the PrimitiveComponent. Same as before, we’re taking the delta between the “OtherPortal” and this portal, adding it to the actor’s current rotation, and then making it do a 180 degree turn (on it’s Z-axis) so that it is facing-out of the portal instead of facing-in.

As another side-note, if you switch-around the A and B pins in the initial Rotator delta here between the two portals, you’ll get an “mirror-like” effect where the angle of reflection coming out of the out-portal is the mirror of the angle of incidence coming in to the in-portal. Great for “magic-mirror-like” portals.

OK, then finally, we’re going to change the velocity of the PrimitiveComponent. This is where all the hard-work we’ve done up to this point pays off. We’re going to use a vector of {1000,0,0} and then rotate it to match the object’s forward-facing vector. Like most other parts of UE, velocity here is expressed, managed, and understood in World Space. We’re effectively doing a TransformDirection here to go from Local Space to World Space… but without having to mess around with getting the right Transform reference :slight_smile: RotateVector is very handy :slight_smile:

You could also save-off the velocity of the object when it begins overlap with the first portal and then use the Vector3.Length as the X value instead of the {1000,0,0} here – if you really wanted to :slight_smile:

And that should about do it. Now anything that uses any shape component for collision (and cooperates with generating Overlap events on the WorldDynamic channel) should be able to use this portal.

Hope this helps.

Thank you for your AWESOME answers :slight_smile: “SetAllLinearVelocity” was the root of this answer I guess. Again thank you.

Sir, I am really sorry for cancelling this answer but I got stuck at the same place again. It seems like these blueprints only let me to teleport and rotate the mesh. What I asked for is: an object enters portal with the velocity of {100,0,0}, it should exit the other portal with velocity of {0,100,0}. Which means if projectile/mesh enters portal moving forward direction it should exit the other portal moving to the right. Have I done something wrong or is this how it is supposed to work?

I’m a few years late, but I saw this when looking for an answer to a similar problem. Hopefully this can help anyone who’s having similar issues these days.
UE provides a ton of tricks for these types of things, but it’s not always easy to find.
For this problem, you just have to have a reference to your actor and your portal-end-point (the direction you want your actor to come out at).
The magic number to keep at hand is the ‘vector length’ of your actor’s velocity. In BluePrint, just drag from ‘Get Velocity’ box and look for ‘VectorLength’.
If you multiply this by the forward vector of the portal-end-point (your teleport end), it will translate your ‘old’ directional velocity into the direction of your teleport endpoint. Ie. you still travel the same speed, but in the direction of your new end-point instead.

1 Like