Title: Openai/69545588-86d8-800f-807e-7602227d6195 - freem URL Source: https://freemwiki.com/index.php?mobileaction=toggle_view_mobile&title=Openai%2F69545588-86d8-800f-807e-7602227d6195 Markdown Content: _This conversation was exported from ChatGPT_[[1]](https://freemwiki.com/index.php?mobileaction=toggle_view_mobile&title=Openai%2F69545588-86d8-800f-807e-7602227d6195#cite_note-1) ## gpt-5-2[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=1 "Edit section: gpt-5-2") ### User: Holding down any movement key sets framerate on fire.[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=2 "Edit section: 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:[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=3 "Edit section: 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)[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=4 "Edit section: The real culprit (most likely)") ##### WASD and arrow keys are bound to built-in UI actions[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=5 "Edit section: 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=6 "Edit section: 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)[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=7 "Edit section: How to fix it (pick at least one)") ##### ✅ 1. Unbind WASD from UI actions (RECOMMENDED)[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=8 "Edit section: ✅ 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=9 "Edit section: ✅ 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=10 "Edit section: ✅ 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=11 "Edit section: ✅ 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=12 "Edit section: ✅ 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=13 "Edit section: 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=14 "Edit section: 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[edit](https://freemwiki.com/index.php?title=Openai/69545588-86d8-800f-807e-7602227d6195&action=edit§ion=15 "Edit section: References") 1. [↑](https://freemwiki.com/index.php?mobileaction=toggle_view_mobile&title=Openai%2F69545588-86d8-800f-807e-7602227d6195#cite_ref-1)["Godot input key issue"](https://chatgpt.com/share/69545588-86d8-800f-807e-7602227d6195). ChatGPT. Retrieved 2025-12-31.