Thanks, but I’m okay on that level. I just didn’t want to do much rewiring. I’m only annoyed that I have to “reproduce” what’s happening in Input…
You don’t. You can just use Input.
Also, FYI, doc for Input’s method.
bool is_action_just_pressed(action: StringName, exact_match: bool = false) const
Returns true when the user has started pressing the action event in the current frame or physics tick. It will only return true on the frame or tick that the user pressed down the button.
This is useful for code that needs to run only once when an action is pressed, instead of every frame while it’s pressed.
versus InputEvent’s
bool is_action_pressed(action: StringName, allow_echo: bool = false, exact_match: bool = false) const
Returns true if the given action matches this event and is being pressed (and is not an echo event for InputEventKey events, unless allow_echo is true). Not relevant for events of type InputEventMouseMotion or InputEventScreenDrag.
They’re not the same; it’s not redundancy.
Links (they go to the proper methods):
Who said they are the same? I posted the code that demonstrates the equivalents. The only thing that is the same is Input.is_action_pressed() and InputEvent.is_action_pressed() and those are even named the same. So I don’t see any problems or inconsistencies whatsoever with how the api is designed.
To answer your question from the title directly: Why doesn’t InputEvent have is_action_just_pressed method?
Because word “just” sounds inadequate in the context of event handling so the test idiom looks a bit different. The equivalent/idiom is, and I repeat this: event.is_action("your_action") and event.is_pressed()
I will begrudgingly agree with that and will leave it at that.
2 Likes
1 Like