Skip to content
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

Merged
merged 12 commits into from
Jul 4, 2024

Conversation

bdach
Copy link
Collaborator

@bdach bdach commented Jul 2, 2024

Namely:

  • Tab to toggle autoplay
  • Ctrl-P to toggle pause
  • F1 for quick exit at initial position
  • F2 for exit at current position

There are more that are currently intentionally unimplemented:

  • Ctrl-B would add bookmarks, but bookmarks are currently completely broken, so that has to get fixed first (Editor does not read properties ignored on BeatmapInfo correctly #20883)
  • F3 would change autoplay speed but I think that's weird and I'd rather have something more universal like a rate adjustment control period, regardless of whether autoplay is or is not active. (You could say this also lies within the purview of testing gameplay with selected mods, which is also one thing that people have been asking for.)

bdach added 4 commits July 2, 2024 14:34
Contains some hacks to fix weird behaviours like rewinding to the start
on enabling autoplay, or gameplay cursor hiding.
@bdach bdach self-assigned this Jul 2, 2024
@@ -442,6 +466,7 @@ public enum GlobalActionCategory
Replay,
SongSelect,
AudioControl,
Overlays
Overlays,
EditorTestPlay,
Copy link
Collaborator Author

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 plain OnKeyDown() which meant that other various bindings like leaderboard toggle were eating these hotkeys when implementing them via OnKeyDown().

@@ -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),
Copy link
Collaborator Author

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.

Copy link
Member

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.

@frenzibyte frenzibyte self-requested a review July 3, 2024 03:12
@frenzibyte
Copy link
Member

  1. osu!catch catcher no longer responds to input after toggling autoplay on then off:

    CleanShot.2024-07-03.at.06.17.49.mp4
  2. (this one is less severe) on any ruleset, holding a game key then turning on autoplay keeps the key pressed indefinitely, and the autoplay cannot hit any object with that key:

    CleanShot.2024-07-03.at.06.22.53.mp4

Copy link
Member

@frenzibyte frenzibyte left a 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.

@bdach
Copy link
Collaborator Author

bdach commented Jul 3, 2024

Issues should in theory be fixed although I wouldn't be surprised to see test failures.

Comment on lines +242 to +248
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);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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.

@frenzibyte frenzibyte self-requested a review July 4, 2024 02:34
@frenzibyte frenzibyte requested a review from a team July 4, 2024 03:39
@frenzibyte
Copy link
Member

Requesting another review mainly for #28705 (comment).

@peppy peppy self-requested a review July 4, 2024 04:13
@peppy
Copy link
Sponsor Member

peppy commented Jul 4, 2024

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 PlayerSettingsOverlay which also allows click/touch access to the various controls.

@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.

@bdach
Copy link
Collaborator Author

bdach commented Jul 4, 2024

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.

@peppy
Copy link
Sponsor Member

peppy commented Jul 4, 2024

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.

@peppy peppy merged commit 73d71d3 into ppy:master Jul 4, 2024
11 of 17 checks passed
@bdach bdach deleted the editor-test-play branch July 4, 2024 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants