Modifierless D-Pad Bound abilities do not work.

[AMAX-NOTE]

Steam-Deck: Turtle WoW

Abilities bound to the d-pad do not work, unless bound with a modifier like LT,RT, ctrl, shift, etc...

[alegaab]

Confirming this on the same setup (Steam Deck / Turtle WoW), and I think I found the root cause plus a fix.

The D-pad keys 5/6/7/8 are the only ones affected because they're exactly the keys the cursor-navigation system borrows. They do double duty: base action buttons (CE_ACTION_5..8) and cursor navigation (CE_CURSOR_MOVE_*). Opening any bag/menu or the config window enters "cursor mode", which saves the current 5-8 bindings, rebinds them to navigation, and is supposed to restore them on exit.

Two things combine to strand keys 5-8 on the navigation bindings:

1. cursor/keybindings.lua -> SaveOriginalDPadBindings() stores whatever is currently bound to 5-8 as the "original" to restore later. If those keys are already on CE_CURSOR_MOVE_* (which happens after a /reload, or after logging out while a bag/menu was open, where RestoreOriginalBindings() never runs and the navigation bindings get persisted by SaveBindings(1)), it faithfully restores them back to navigation, so they never return to the action buttons.

2. keybindings.lua -> Initialize() only runs SetupDefaultBindings() when no CE_ACTION has a key. Since 1-4/9/0 still have their keys, the whole default-repair is skipped, so the missing 5-8 are never re-bound on login.

This also explains the common workaround (clicking "Reset Bindings" in the config): it works, but only while the menu stays open, because closing the menu fires RestoreOriginalBindings(), which re-applies the stale navigation bindings captured when the menu opened, undoing the reset. Modifier combos (LT/RT/ctrl/shift + key) are never touched by cursor mode, which is why those keep working.

Fix - two small changes make it self-repairing:

diff --git a/keybindings.lua b/keybindings.lua
--- a/keybindings.lua
+++ b/keybindings.lua
@@ -270,25 +270,18 @@ function ConsoleExperienceKeybindings:SetupDefaultBindings()
 end
 
 function ConsoleExperienceKeybindings:Initialize()
-    -- Check if any CE_ACTION binding already has a key assigned.
-    -- We scan all 40 slots because some may be proxied to system actions (like JUMP),
-    -- which replaces their CE_ACTION_X key. On a fresh install, none will have keys.
-    -- This is more robust than a saved variable flag because it directly reflects
-    -- the actual WoW binding state and can't get out of sync.
-    local hasExistingBindings = false
-    for i = 1, 40 do
-        if GetBindingKey("CE_ACTION_" .. i) then
-            hasExistingBindings = true
-            break
-        end
-    end
-    
-    if not hasExistingBindings then
-        CE_Debug("No CE bindings found, setting up defaults...")
-        self:SetupDefaultBindings()
-    else
-        CE_Debug("Existing CE bindings found, skipping default setup")
-    end
+    -- Always run the default-binding setup. SetupDefaultBindings() is idempotent:
+    -- for each action it only assigns a key when that action currently has NO key
+    -- (see the "if not currentKey" guards), so existing bindings and any keys you
+    -- customized through the Blizzard UI are preserved.
+    --
+    -- The previous version skipped this whenever *any* CE_ACTION already had a key.
+    -- That left a gap: if some default keys went missing while others survived
+    -- (classically the D-pad keys 5-8 getting stranded on cursor-navigation actions
+    -- after a /reload or a logout while a bag/menu was open), the missing ones were
+    -- never restored. Running the idempotent setup every login repairs those holes.
+    CE_Debug("Ensuring default keybindings are present (idempotent setup)...")
+    self:SetupDefaultBindings()
     
     -- Initialize and apply proxied actions (replaces old useAForJump system)
     if ConsoleExperience.proxied and ConsoleExperience.proxied.Initialize then

diff --git a/cursor/keybindings.lua b/cursor/keybindings.lua
--- a/cursor/keybindings.lua
+++ b/cursor/keybindings.lua
@@ -87,11 +87,20 @@ function CursorKeys:SaveOriginalDPadBindings()
     CE_Debug("Saving original D-pad bindings:")
     for _, key in ipairs(dPadKeys) do
         local action = GetBindingAction(key)
-        if action and action ~= "" then
+        -- Never remember a cursor-navigation action (or an empty binding) as the
+        -- "original" state. If we did, the D-pad keys would stay stuck on navigation
+        -- after cursor mode ends, which is the bug that broke keys 5-8. The correct
+        -- resting state for these keys is always the matching action button
+        -- (key "5" -> CE_ACTION_5, etc.). If the slot happens to be proxied (e.g. to
+        -- JUMP), proxied:ApplyAllBindings() runs right after RestoreOriginalBindings()
+        -- and re-applies the proxied action, so forcing CE_ACTION here is safe.
+        if (not action) or action == "" or string.find(action, "^CE_CURSOR_") then
+            action = "CE_ACTION_" .. key
             self.originalDPadBindings[key] = action
-            CE_Debug("  Key " .. key .. " = " .. action)
+            CE_Debug("  Key " .. key .. " = " .. action .. " (forced to action default)")
         else
-            CE_Debug("  Key " .. key .. " = (none)")
+            self.originalDPadBindings[key] = action
+            CE_Debug("  Key " .. key .. " = " .. action)
         end
     end

After this, keys 5-8 are repaired on every PLAYER_ENTERING_WORLD (the setup is idempotent: it only fills keys that have none, so custom bindings are preserved), and cursor mode can no longer "remember" a navigation action as the resting state for the D-pad: on exit those keys always go back to CE_ACTION_5..8. For proxied slots (e.g. A = JUMP) this stays correct because proxied:ApplyAllBindings() already runs right after RestoreOriginalBindings().

Tested on Steam Deck / Turtle WoW: the D-pad abilities now work straight from login, with no manual reset. Happy to open a PR if that's easier.

ConsoleExperienceClassic-0.17.3-dpadfix.zip