Setting up a simple Directional jump in the direction the player is facing, which is simple enough. But my section where I determine if the character is standing in place to get a 1 and 0 value seems convoluted.
TLDR; All nodes are labelled for what they’re intended to do, any advice to reduce this please?;
Essentially, I’ve seen advice to just use forward vector to get a directional jump, but what it lacks is when the player is standing still, those values are still active, so the character jumps into the direction even if they are not moving towards that direction. I tried vector length as well as velocity, but those are also locked to 1 and/or -1, so multiplying that with the direction velocity still doesn’t allow the player to jump in place. I’ve forced it step by step to get to give me a value between 1 and 0 using the current velocity of the player, but my intuition is telling me that this is more computing and math to get something as simple as “if the character is moving then xy=0 but z = +value, if the character is not, then which direction are they facing and jump towards that”
I’m sure there is a much more efficient way to achieve this, any advice to reduce this please?
Only use the x & y components of the velocity by either splitting the struct pin or breaking the vector, then connect the corresponding axis to a Make Vector node.
After normalizing the new vector, multiply it by a desired value and determine the jump height by using the addition (+) node
Connect the result to the Launch Velocity pin of the Launch Character node and that’s it, you don’t need any of the other stuff there
Helped me see aspects that I was overlooking and confused by. This works great, except one aspect that I need for these mid-air jumps, is that when not using the forward vector, the player cannot change direction when mid-air with the jumps, as the velocity is carried over from the current jump, so if one is to jump twice, even when changing the rotation/direction of the player before the second jump, they persistently jump towards the previous/last direction, as the velocity is still driven that way.
But this def helps, I’ll test out a bit more to see where I can apply the influence of the change in forward vector/direction
In that case, just get a Rotate Vector node and assign the vector value as (x = 1, y = 0, z = 0). Then get the control rotation, split it to expose it’s components, also split the purplish-grey pin of the Rotate Vector node, and connect the control rotation’s rotation value around z axis into the exposed z (yaw) pin of the Rotate Vector node. Now you can use the result instead of the velocity vector and the rest is the same
Oh and btw, if you want to control the dash-jump rotation using inputted movement direction rather than the camera direction, just use the input vector instead of the velocity vector.
Ah I see, will test that. Maybe a dumb question before trying it out, but how will this determine when to jump in place when the character is not moving? Won’t the player always have a rotation value no matter where they look? For example when there is no movement input the character just jumps straight up, moving towards the look-direction launches them towards that direction.
Oh great catch! You can fix that by using a Make Vector node and assigning it the +x direction vector, and multiplying it with the normalized velocity and then rotate the result if you want to control the direction using the camera. If you’re gonna go with the other approach that I included in my edit, that’s not gonna be a problem anyway.
Awesome thanks! Will test this tomorrow morning after work, but seems like it will work just like intended. Will see how both approaches feel using input/rotation
