-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reimplement missing gameplay test hotkeys from stable #28705
Conversation
Contains some hacks to fix weird behaviours like rewinding to the start on enabling autoplay, or gameplay cursor hiding.
@@ -442,6 +466,7 @@ public enum GlobalActionCategory | |||
Replay, | |||
SongSelect, | |||
AudioControl, | |||
Overlays | |||
Overlays, | |||
EditorTestPlay, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These getting a separate section will likely look gratuitous but it bypasses several issues:
- If they were to be implemented as non-rebindable, they wouldn't be listed anywhere, so there'd probably need to be text that explains that these exist
- F1 and F2 are already used in the editor section (for compose/design tabs), and keybindings must be unique within a section
- This also solves various input priority weirdness. As it stands,
KeyBindingContainer
takes precedence over plainOnKeyDown()
which meant that other various bindings like leaderboard toggle were eating these hotkeys when implementing them viaOnKeyDown()
.
@@ -100,7 +104,6 @@ public static IEnumerable<GlobalAction> GetGlobalActionsFor(GlobalActionCategory | |||
new KeyBinding(new[] { InputKey.Control, InputKey.Shift, InputKey.F }, GlobalAction.ToggleFPSDisplay), | |||
new KeyBinding(new[] { InputKey.Control, InputKey.T }, GlobalAction.ToggleToolbar), | |||
new KeyBinding(new[] { InputKey.Control, InputKey.Shift, InputKey.S }, GlobalAction.ToggleSkinEditor), | |||
new KeyBinding(new[] { InputKey.Control, InputKey.P }, GlobalAction.ToggleProfile), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is moved/deprioritised to the overlay toggle section because in its previous place it was blocking the quick pause hotkey.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checks out since it's an overlay toggle key binding in itself.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a side note, it's pretty interesting to see that the ability of toggling autoplay in a Player
screen works out of the box like that 😅 (unless there's an existing case of this that I did not know about). Requesting changes for the points mentioned above.
Issues should in theory be fixed although I wouldn't be surprised to see test failures. |
new MouseButtonInput([], state.Mouse.Buttons).Apply(state, handler); | ||
new KeyboardKeyInput([], state.Keyboard.Keys).Apply(state, handler); | ||
new TouchInput(Enum.GetValues<TouchSource>().Select(s => new Touch(s, Vector2.Zero)), false).Apply(state, handler); | ||
new JoystickButtonInput([], state.Joystick.Buttons).Apply(state, handler); | ||
new MidiKeyInput(new MidiState(), state.Midi).Apply(state, handler); | ||
new TabletPenButtonInput([], state.Tablet.PenButtons).Apply(state, handler); | ||
new TabletAuxiliaryButtonInput([], state.Tablet.AuxiliaryButtons).Apply(state, handler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://discord.com/channels/188630481301012481/188630652340404224/1258027155208536115 for rationale for this atrocity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to think that this is a workaround for a bug caused by the way replay input handling / KeyBindingContainer.Trigger{Pressed,Released}
works, and is fine to exist for now.
Replay input handler should have full control over the ruleset input manager's input state, but currently they only mutate the state of the KeyBindingContainer
, and that's not good because the state of KeyBindingContainer
will still be influenced by the input manager's input state, which the ReplayInputHandler
does not touch.
When user switches from gameplay to autoplay while holding a key, KeyBindingContainer.TriggerReleased
will get called on the action associated with the key, but nothing happens because KBC still sees the corresponding key in a pressed state and because simultaneous binding mode != all (see discord for more info).
Either the replay input handler should update the state of the input manager rather than the key binding container, or TriggerPressed
/TriggerReleased
should be disassociated with the state of the parenting input manager by some way. None of these methods seem that simple to work with, so I'm fine with performing a manual reset here for now.
Requesting another review mainly for #28705 (comment). |
In stable, these hotkeys are explained in a raw text string top-left of test play mode. I'd like to see something similar, but probably better implemented as a tool container in @bdach any thoughts on this part? I'm fine with getting this in as-is but also don't want the visibility of these keys to be forgotten. |
Having these rebindable and show up in the keybinding panel was supposed to be my solution to the issue of discoverability of these, but I guess I don't see any reason not to try and add these back as actual on-screen buttons with a tooltip that shows the relevant key combination I guess. |
Yeah I get that they are there, but that likely isn't going to be the first place people look to find hotkeys. In stable we used to have a help overlay which revealed all the hotkeys that aren't necessarily visible otherwise, maybe that can be something we can explore in the future. Going to get this in first, regardless. |
Namely:
There are more that are currently intentionally unimplemented:
BeatmapInfo
correctly #20883)