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

This conversation was exported from ChatGPT

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:

InputEventKey (pressed=true, echo=true)

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):

func _input(event):
    if event is InputEventKey and event.is_echo():
        return

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

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

For movement, never rely on _input().

Correct pattern:

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

This:

• Avoids echo spam
• Avoids UI input paths
• Is deterministic

✅ 4. Make sure movement logic isn’t cumulative

Common hidden bug:

velocity += direction * speed  # BAD

Should be:

velocity = direction * speed   # GOOD

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:

func _input(event):
    if event is InputEventKey:
        print(event.scancode, event.is_echo())

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.