Character Moves Faster Diagonally... How to fix please?

I have noticed that it moves faster diagonally… How to stop this?

Clamp was not originally there, but I have been placing it in various places because supposedly it is a way to fix, but I have not been able to get it to fix…

Really appreciate any assistance.

The axis supplies a 0-1 range, so clamping them to 0-1 will do nothing at the moment. What you need is for both of them to be in communication with each other, so that if move forward is at 0.8, move right gets clamped to 0.2. that should limit overall movement to 1. not at my pc right now so I can’t test, but if you take the move forward axis, invert it, and plug it into the max of the move right, as the number gets larger on that axis, the clamp will get lower, slowing movement. repeat for move right axis to move forward clamp max. You will need some more math in there so that the player can still transition to diagonal from full run though, Sort of like a priority to move right that always slows move forward. (or it might work out of the box)
Edit: for the inversion, the “map range clamped” node will do it, axis value goes to the main pin, then in the input fields type 0 and 1 and on the output fields type 1 and 0. now 1 will = 0 and vice versa.

Subtract the axis value from 1.
then whatever is left is the max clamp value of the other axis.

You should be able to check both and set the max on both and have it working with that very basic math.
at .5 on A, you can only reach .5 on B. And vice-versa.

Well, ok. Not that simple because the axis is also -1 to 1. Not just positive.
So there’s definitely more that would need to happen, but that’s probably a good way to start at it.

Depending on the setup: since you’re using a Pawn, you can also add a Floating Movement Component and have it clamp Max Speed:

Screenshot_2.jpg

No matter how much Movement Input is accumulated this frame, the pawn will not exceed this value.

edit: just noticed you mentioned a *character *- which gives you even more control, actually. Unless you’re not using components for movement, that is.

Sorry, but is it possible to get an example? This is hurting my head trying to figure out and calculate… Cannot seem to get it working no matter how I do it.

just add a divide to the scale value float right before the scale value input. divide by 2.

Why do you multiply the scale ? Did you verify if all are constant ? Take a look at the original ThirdPerson blueprint take the simple code there is. normaly it’s not faster to run on X and Y. It depend on a direction vector and a speed. So it’s same speed on every directions.
Scale is a sort of speed 0-1 , same on every directions, no ? Or… are you on a grid system ?

I know this is an older topic but I stumbled across this problem as well.
Probably not the best solution, works for me. I used the absolute values of my inputs (A and B) and (save-) divided them through each other (A/B and B/A). Then I determine the lowest values out of this. This returns 0 if we are going straight and 1 if diagonal. This value can be used to remap the sum of my absolute inputs from 0 to 1 or 0 to 2 into our wanted range 0-1.
This value can then be multiplied to our normalized direction.

1 Like

Revival of this thread with another solution:

The problem with this solution is, that you run into problems as soon as you want to use controller values. The character will move always with full speed and not acting properly to joystick input.

Ah good catch! I think with a vector size clamp it should fix it

Yes, this somehow works as an approximation, but it is not correct. When input X and Y = 1 you have a vector length of 1.41 something. You are clamping it to 1, so you basically ignoring 40% of your input.
You got a linear transition between input X and Y = 0 to input X and Y = 0.7. After this your output will be clamped to the maximum.
I think it is not possible to calculate this without a more complicated solution as the one I posted.

1 Like

this is the solution my friend, grab the movement axis, make em a vector and normalize that vector, that way both axis are comunicating to each other and making the resultant vector lenght of 1, from there, grab the axis and use that as the scale, here is my code, have in mind that i have a division to dampen a little bit the force, but u should be able to remove that and still be ok

2 Likes

I can testify for this, this work for me. :smiley:

2 Likes

Hah. Moving diagonally being faster is a classic math error in gaming.

Earliest game I remember it happening was Everquest 1. :sweat_smile:

1 Like

Thank you for posting this, it works like a charm!

1 Like