Rebuild the hotkey lookup whenever bindings change - #3082
Merged
sprunk merged 2 commits intoJul 21, 2026
Merged
Conversation
sprunk
reviewed
Jul 2, 2026
burnhamrobertp
force-pushed
the
bug/hotkeymap-rebuild-on-mutations
branch
from
July 8, 2026 20:14
61939bb to
adb8914
Compare
…uild-on-mutations # Conflicts: # rts/Game/UI/KeyBindings.cpp
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The reverse "action -> keys" lookup (what
Spring.GetActionHotKeysand the command-icon hotkey labels use) can be stale, because it's only rebuilt at the tail ofExecuteCommand. At startup the default and user bindings are loaded byGame.cppcallingLoadDefaults()andLoad()directly, which skip that path, so the cache sits empty until the first keybinding command runs. Checked in a local build:GetActionHotKeys("pause")returns nothing at boot and is populated after any command. It doesn't surface in BAR because itscmd_bar_hotkeyswidget does akeyreloadon load, which rebuilds the cache.This tracks whether bindings actually changed (
hotkeysDirty, set on real bind/unbind/etc.) and rebuilds the cache once at the end of the outermost operation when something changed, soLoadDefaults()/Load()now refresh it on their own and the startup gap is gone. As a side effect it also stops the needless rebuild on commands that change nothing (keydebug, redundant binds).Verified with a small game:
GetActionHotKeys("pause")is now correct at startup, and a normal bind still updates it.This came out of review on #3081 (the KeyBindingsChanged callin), where badosu pointed out the cache should be rebuilt whenever bindings change. It's a pre-existing issue independent of that PR, so it's split out here. The two touch the same spot in
ExecuteCommand, so whichever lands second will have a small conflict, and thehotkeysDirtyflag is the accurate "did anything change" signal that #3081's event could later use instead of its own.Used Claude to help with this.