Lukegao: by freem.ai...

2025-12-31T05:24:35Z

by freem.ai...

New page

{{DISPLAYTITLE:Godot input key issue}}

''This conversation was exported from ChatGPT''<ref>{{cite web|title=Godot input key issue|url=https://chatgpt.com/share/69545588-86d8-800f-807e-7602227d6195|publisher=ChatGPT|access-date=2025-12-31}}</ref>

== gpt-5-2 ==
=== User: Holding down any movement key sets framerate on fire. ===
Holding down any movement key sets framerate on fire.

Whenever I hold down WASD or arrow keys (movement buttons), the framerate drops DRAMATICALLY, can go below 1 FPS. I then tried remapping movement to IJKL instead of WASD and somehow using that magically avoided the problem.

I've searched for every func \_input, \_unhandled\_input and the like. Nowhere I can find the culprit. Debugger profiler doesn't pinpoint any particular function. Spam-tapping the keys for movement works okay, it's the holding down input keys that wrecks havoc. Seems it starts mild and then gets stronger the longer the game has been running.

Any ideas?

=== Assistant: This very strongly smells like a Godot input + UI / key-echo interaction, especially because: ===
This very strongly smells like a Godot input + UI / key-echo interaction, especially because:
* WASD + arrow keys cause the problem
* IJKL does not
* Tapping is fine, holding is catastrophic
* Gets worse over time
* Profiler doesn’t point to a single hot function

Those clues narrow it down a lot.

==== The real culprit (most likely) ====

===== WASD and arrow keys are bound to built-in UI actions =====

By default, Godot maps:
* ui_left / right / up / down → Arrow keys AND WASD

If you have any Control nodes (UI) in the scene tree — even invisible ones — holding those keys triggers UI navigation every frame, which can:
* Recalculate focus
* Traverse the scene tree
* Fire _gui_input
* Trigger theme/layout updates

This does NOT show clearly in the profiler, because it’s spread across engine internals.

When you switch to IJKL, those are not bound to UI navigation — problem disappears.

✅ This matches your symptoms perfectly.

==== Why holding makes it worse ====

Holding a key generates echo events:

<syntaxhighlight lang="gdscript">InputEventKey (pressed=true, echo=true)

</syntaxhighlight>

So every frame:
* _input()
* _unhandled_input()
* _gui_input()
* Focus navigation
* Any accidental logic tied to input

…keeps firing.

If you accidentally append, spawn, or register anything on key-hold, it snowballs.

==== How to fix it (pick at least one) ====

===== ✅ 1. Unbind WASD from UI actions (RECOMMENDED) =====

Go to:

Project Settings → Input Map

Remove:
* W, A, S, D
* Arrow keys (optional)

From:
* ui_up
* ui_down
* ui_left
* ui_right

Unless you explicitly want keyboard UI navigation.

===== ✅ 2. Ignore key echo events =====

If you use _input(event):

<syntaxhighlight lang="gdscript">func _input(event):
if event is InputEventKey and event.is_echo():
return

</syntaxhighlight>

This alone fixes many “holding a key destroys FPS” bugs.

===== ✅ 3. Use Input.is_action_pressed() instead of _input =====

For movement, never rely on <code>_input()</code>.

Correct pattern:

<syntaxhighlight lang="gdscript">func _physics_process(delta):
var dir := Vector2.ZERO
if Input.is_action_pressed("move_left"):
dir.x -= 1
if Input.is_action_pressed("move_right"):
dir.x += 1

</syntaxhighlight>

This:
* Avoids echo spam
* Avoids UI input paths
* Is deterministic

===== ✅ 4. Make sure movement logic isn’t cumulative =====

Common hidden bug:

<syntaxhighlight lang="gdscript">velocity += direction * speed # BAD

</syntaxhighlight>

Should be:

<syntaxhighlight lang="gdscript">velocity = direction * speed # GOOD

</syntaxhighlight>

Holding a key would otherwise accelerate forever, tanking physics.

===== ✅ 5. Check for accidental allocations on input =====

Search for:
* append
* add_child
* connect
* push_back
* new()

Anything that runs per input event will explode on key hold.

==== Quick diagnostic test ====

Add this temporarily:

<syntaxhighlight lang="gdscript">func _input(event):
if event is InputEventKey:
print(event.scancode, event.is_echo())

</syntaxhighlight>

Hold W and watch the flood.
Hold I and compare.

You’ll see the difference immediately.

==== TL;DR ====

This is almost certainly Godot’s default UI input bindings + key echo.

Unbind WASD from ui_*, ignore echo events, and handle movement via
Input.is_action_pressed() in _physics_process().

If you want, tell me:
* Godot version
* Whether you have any Control nodes in the scene
* How movement is currently handled

…and I can pinpoint it down to the exact line.

== References ==
<references />

[[Category:ChatGPT Shares]]
[[Category:openai]]

Openai/69545588-86d8-800f-807e-7602227d6195 - Revision history

Lukegao: by freem.ai...