Neither the dash nor the teleport works as indended

Im creating a 2d multiplayer fighting game. I know that the multiplayer part is hard in it of itself so lets leave that for another day. The problem I have is with my dash and with my teleport

So I want to have a ninja that can dash or teleport. Here is the logic for my code
I use paper ZD with a combo state machine and a movement state machine.

Press the dash button - > do some checks - > jump to Dash node in the movement state machine - > dash 1 animation plays (kind of like a ramp up) - > animation finishes - > dash 2 node enters - > on entered node i have a custom event called DashMovement → logic of dash /teleport plays out → animation for dash 2 plays and it ends(i hope thats how it works anyway) → back to idle and the movement lock/dash lock is disabled

Now for the dash movement part. Launch character is pretty…difficult as one might say. especially when dashing off platforms which the game will have many. Im wondering if there is a fix for that or a different method.

Now for the teleporting part…I have a tiny problem. My character teleports the right amount on the X axis…but for some goddam reason I end up in the air.

I would like a fix for both if possible since im planning my future wizard to have a teleport anyway.
Thank you to everyone who took the time to read this

I just started UE but might be able to help a little bit.

I’ve played with LaunchedCharacter and what it basically does is (assuming no XYZ overrides):

  • Add velocity vector to your character
  • Set player movement mode to Falling

What this mean is that, say you launch your character on X at a speed of 5000cm/s, and your character is currently standing still. And we have the default braking deceleration while falling of 0 (you don’t loose your X momentum while in the air).

Note: I cannot yet explain exactly why&when the falling states switches from Falling to Walking, I just know it doesn’t happen directly and takes couple frames to kick in.

Not accurate but gives an idea of what happen each frame, all happening at consistent 120fps:

  1. 5000/120 = 41.66cm distance covered – Falling
  2. 5000/120 = 41.66cm distance covered – Still falling, so initial speed is unchanged
  3. Still falling add another 41.66cm
    …few more of these…
  4. Mode switch to Walking, you start decelerating automatically due to ground friction and because you are above you max speed.
    let’s say 3800/120 = 31.66 cm distance covered
  5. 22 cm
    etc until complete stop - which doesn’t take long

Note that summing all of these value will not be equal to 50m distance covered - whether you start grounded or not, we are only telling the engine “Hey, this guy now has + 50m/s move speed on X”

Now you said that something was off when dashing off platforms. I guess by that you meant you are flung forward way more than expected.
If we consider the above example, dashing from a platform ledge would mean you start from Falling mode (since that’s what launch character does automatically, regardless of your character actually touching the ground), as soon as you leave the platform, you will again be in Falling movement mode, where friction is null / no deceleration. So you will keep this momentum until gravity brings you to the ground —> more distance covered.

Few things you can look at on your character movement component and play around with to have a feel of how it affect physx:

  • Air control
  • Braking Deceleration for all movement mode
  • Ground Firction
  • Falling Lateral Friction
  • Braking Friction Factor
  • Max Walk Speed
  • Gravity Scale

Anyhow, as you can see LaunchCharacter depends on many variables.
So if you have to have tight and predictable movement in your game, such as “I want to move exactly X units when dashing”, you would have to make sure that all of them have the correct values when ticking depending on the current context of your character. Which I’m sure could become quickly messy if not well understood (not that I understand it very well yet)
Your approach with SetActorLocation sounds better suited for a precise dash as physx aren’t involved in this case.

As for the teleport method… I have no idea based on this blueprint alone, seems correct.
Some ideas though:

  • double check other things that could move you character on the Z axis (root motion or any other mechanics that could trigger automatically)
  • good way to identify if the issue is within this teleport mechanic would be to setup a new character on a fresh project, with just this mechanic in place, and see if the character moves correctly - if it does, this BP code is fine and the problem lies somewhere else.

I remember there’s also a AddActorLocalOffset, could be handy :person_shrugging:

hope that helps.

Hello. THank you so so much for answering.

First of all I would like to say that ur way ahead of me if you can kind of understand what you said regarding the launch function. To be fair even if i did understand it, it doesnt seem like the best approach or a fun one. I might as well use a slide one. But in my game I dont want to slide.

Thank you for confirming my teleportation method seems better suited. I just got back from work. I still dont know what causes my character to move in the Air.

I also tried the addactorlocaloffset. The only problem is that I cant get my goddam character to dash left. I have the exact same position code as the one above with the teleportation one. It literally wont dash left

I cant believe i spent so much time for a stupid dash. Thank you for the help . I hope i will find a way

Sorry if it wasn’t clear. I was just trying to highlight the difference between the two.
—> LaunchCharacter is physics based, where SetActorLocation is not

Consider the following simple blueprint:

If I turn off gravity using the G key, and then press F once, my character will move at a consistent speed/velocity of 1000cm/s upward (no acceleration).

However, if I had used SetActorLocation, when pressing G once, my character would have only moved 1000cm up since we haven’t modified our actor velocity.

That basically highlights some of the difference between the two methods: physics

I am 99% sure the problem doesn’t come from the DashMovement implementation itself and it’s somewhere else. Try with a gravity flip, unplug the execution of DashMovement from SetActorLocation, while simulating, flip gravity and press your dash key. If you still go up, it’s definitely because of something else.

While I’m at it, you could check out this thread if you haven’t already, similar topic (someone also provide a good example solution using actor location, similar to yours, fixed dash length):

Hello I literally found the fix for one of them last night before you wrote this reply. The problem was literally the math of it. For some reason i was adding up the actor location with the float of the multiplication from get actor forward vector and my teleport distance. and if you wanted to teleport left…it wouldnt really turn out well since it would be 2 negatives resulting in a positive so basically teleporting right.

Thank you for the further explanation. I will move forward with the teleport part. I still havent tried to find a fix for setactor location but not sur eif i will use it. Although i will save this thread for when i do.

Thank you!

1 Like