#Change movement code to use unhandled_input

29 messages · Page 1 of 1 (latest)

cobalt viper
#

I currently have a movement script using _physics_process(), and I'd like to switch it to _unhandled_input(), as I've heard that it's better to use. The problem is that I want my code to not run differently depending on the framerate. When using _physics_process(), I can use the delta variable to achieve this. But I can't find anything about this with unhandled_input(). Is there a way to achieve this?

icy ingot
#

To get deltatime; you could either do
Node.get_process_delta_time(), or

var dt
func _process(delta):
  dt = delta

func foo():
  movement * dt
  ...
#

I dont see why you want to avoid _physics_process() tho.

limpid kraken
#

I'm in a similar boat, but the initial assumption is flawed : Some actions are discrete and some are continuous. Jumping is discrete since it only happen when you press the button, where anything related to movement is continuous since the joystick have values. Access to the physics to query raycast is available in _physics_process, so those must be done there.

fortunately, velocity can be modified at will, so my pseudo code look like this :

extend kinematicbody
var velocity = Vector3.ZERO
func physics_process(delta):
velocity = move_and_slide_with_snap(velocity) # first thing to do is move

modify the velocity for the next frame.

velocity += -global_transform.basis.y * gravity_force

func _unhandled_input(event):
if event is action (JUMP) and is_on_floor():
velocity = Plane(up_direction).project(velocity) + global_transform.basis.y * JUMPFORCE

rough junco
#

Even if you use _unhandled_input entirely for handling your input, you would still only use delta within _physics_process. You would update some variables in _unhandled_input, then _physics_process would use those values to know what to do

rancid mirage
# icy ingot I dont see why you want to avoid `_physics_process()` tho.

would usually want to avoid using _physics_process for capturing inputs, when you want your gui to intercept inputs

eg, your clicking on item bar, and the character is moving towards the direction
(Would want to avoid that)

then for key inputs, when you have settings opened, it would be weird to still be able to control your character

Side note: To consume key inputs, you'd need to grab_focus from the popup

and yes there are workarounds, but they're very fragile and error prone

icy ingot
cobalt viper
pastel delta
rough junco
#

The input function should only handle input, not movement

pastel delta
#

This ^

#

So use the input func for the input of the movement and then use that data inside the process func like I explained above

cobalt viper
pastel delta
cobalt viper
rancid mirage
cobalt viper
# rancid mirage do you mean that when you click to move, there's a noticeable delay? or somethin...

do you mean that when you click to move, there's a noticeable delay? or something else?

I don't use click to move, i'm using WASD. What I mean is even after the rotation, the cube will continue moving in the original rotation for a second

also btw are you using _unhandled_input to check whether it is still pressed?

I check if a movement input is being pressed, and if so run the movement function

rancid mirage
#

In any case, if this solution causes more problem that in solves, then I suppose, just using physics_process for everything, might be the solution for your project

cobalt viper
rancid mirage
cobalt viper
rancid mirage
cobalt viper
#

yeah, it continues moving in the previous direction for a sec

rancid mirage
icy ingot
#

Do you have any smoothing going on?

#

Maybe adding/subtracting from your movement vector in places where you shouldn't?

cobalt viper