I’m using this hacky method to fix hooking air movement, but I feel like there is a cleaner way to go about it. If you know lmk.
Dir is a normalized vector.
Code:
#Check if you should accel or deccel
var moving = true if dir else false
#Set up smooth horizontel air movement
var flat_speed = Vector2(speed.x, speed.z)
var flat_dir = Vector2(dir.x, dir.z)
flat_speed = flat_speed.move_toward(flat_dir * air_speed, (air_accel if moving else air_deccel ) * delta)
#Gravity
speed.y = move_toward(get_real_velocity().y, -fall_speed, gravity * delta)
#Air Strafing
speed.x = falt_speed.x
speed.z = falt_speed.y
This is what I came up with based on what pennyloafers said:
#Check if you should accel or deccel
var moving = air_accel if dir else air_deccel
#Smooth air strafing
var flat_speed = speed.move_toward(dir * air_speed, moving * delta)
speed.x = flat_speed.x
speed.z = flat_speed.z
#Gravity
speed.y = move_toward(get_real_velocity().y, -fall_speed, gravity * delta)
Why do you have a variable named “flat_speed” ? that moves_towards a point in space ? …
What is the meaning of “flat” ? … “speed” is a measurement. how can a measurement move ?
Shouldn’t that be the “thing” which is actually moving ? Maybe the “wind” ?
Also, I see a lot of calculations done as an assignment value to variables when it may be much better to use getter functions and then have a main function which executes these operations.
I’m trying to help and give my perspective, hope it does not come across as unfriendly.
My question has already been solved but I’ll tell you anyways.
Normally, when doing player movement, you need to accelerate and decelerate your player in the direction they want to go. This is extremely easy and can be implemented using 1 line of code. But when it comes to air movement you need to separate the vertical movement to create gravity. You can just set the XYZ velocities separately but then the X and Z vectors won’t be linked together which causes buggy movement when going in a diagonal direction in WorldSpace.
The method I used solves this issue but is over complicated. Thankfully pennlyoafers’s method was exactly what I was looking for.
move_toward can be used as a standalone function that moves one value closer to another, in this case speed.y which is a float. If you use it like vector3.move_towards() it moves that vector towards another.
mm… that’s strange. is the documentation lacking then ? … is there a place where I can read about it ? I’m curious why it’s able to work with three arguments.
Oh I see, these are two different methods. One is for 3D vectors and the other one for - not really sure - but instead of returning a vector it returns a float.
This is a little bit confusing, not sure if having different methods in the engine with the same name is a good idea - probably not