how do I properly set up player controls with _unhandled_input?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By AsCiiexe

I’ve heard that it’s not ideal to use _input() for player controls because it can interfere with menus and UIs, but from what I can see _unhandled_input() works quite differently, when executed it only gives the inputs one at a time through the “event” parameter instead of all at the same time, so if I want to check multiple inputs at once for an action I have to juggle with a few variables as far as I can tell, also it runs after _physics_process() so if I want to use the input information there I have to store it and use it in the frame after the input has taken place.

This seems quite messy, am I misunderstanding how _unhandled_input() works or is there a better way to use _unhandled_input() in place of _input()?

:bust_in_silhouette: Reply From: exuin

_input also gives the events one at a time through the event parameter. You might be confusing it with the Input singleton, which represents the state of all input events at once. You can call functions on Input inside the _unhandled_input function so you don’t need to juggle variables.

I thought the input singleton was just another way of referencing Input! Yeah that makes more sense. So is there a way of getting the inputs from _unhandled_input while still being able to use that information for physics_process on the same frame? Or will I only be able to use it on the next frame?

AsCiiexe | 2021-09-29 14:48

Yeah just call Input.is_action_pressed or another method

exuin | 2021-09-29 14:53

does that mean that if a control node consumes the input, Input.is_action_pressed functions on physics_process won’t be triggered by that same input?

AsCiiexe | 2021-09-29 14:57

It still will

exuin | 2021-09-29 16:32

okay, I guess it’s easy to work around that then, thanks!

AsCiiexe | 2021-10-01 16:48