-
Notifications
You must be signed in to change notification settings - Fork 411
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
Change PassThroughInputManager
to not sync new presses outside Handle()
#6221
Conversation
I dunno. I threw the flag proposal out as a potential way of avoiding complications. But I look at this diff and see more complications. I'd like this to be simpler. Isn't it an option to (spitballing) make At the least the flag needs to be named different. Something like |
I think you're misunderstanding the issue, the input manager of the resume overlay has nothing to do with this. Gameplay is the primary and full user of To reiterate, the point of this change is to make the input manager that contains the hit objects not sync new presses using
I suggest we do away with the flag and conform to the new behaviour introduced by this PR, and reassess when something bad happens. |
I don't like the increase in complexity here. I'd be tentatively okay with using the same logic as the mouse buttons, but I also have long forgotten why mouse buttons specifically differed. |
The mouse button behaviour looks to have just been added as-is since #1682 with no specific reason. Re-reading the description, perhaps it's to block mouse buttons from appearing pressed if they were intercepted from reaching the |
I'm not saying yes or no to this until you tell me if #1672 is going to regress, and if yes, what local patch to fix it you're proposing here. |
I touched on that already in ppy/osu#9658 (comment) (see final point in bullet 2, where I linked the issue). But that being said, the diff will not change by much actually: diff --git a/osu.Framework/Input/PassThroughInputManager.cs b/osu.Framework/Input/PassThroughInputManager.cs
index 40855fa26..e82e66ab6 100644
--- a/osu.Framework/Input/PassThroughInputManager.cs
+++ b/osu.Framework/Input/PassThroughInputManager.cs
@@ -48,15 +48,6 @@ public virtual bool UseParentInput
private bool useParentInput = true;
- /// <summary>
- /// Whether to synchronise newly pressed buttons on <see cref="Sync"/>.
- /// Pressed buttons are still synchronised at the point of loading the input manager.
- /// </summary>
- /// <remarks>
- /// This does not apply for mouse buttons.
- /// </remarks>
- public bool SyncNewPresses { get; init; } = true;
-
public override bool HandleHoverEvents => UseParentInput ? parentInputManager.HandleHoverEvents : base.HandleHoverEvents;
internal override bool BuildNonPositionalInputQueue(List<Drawable> queue, bool allowBlocking = true)
@@ -251,7 +242,7 @@ protected virtual void SyncInputState(InputState state, bool applyPresses)
}
}
- if (SyncNewPresses || applyPresses)
+ if (applyPresses)
{
// since we have a flag for syncing new presses, it is expected that we apply mouse button presses as well.
// this wasn't the case before the existence of the flag for another reason that's irrelevant here, The |
Well I dunno what to say at this point if that is the extent of the changes incurred by the flag. You're basically presenting two choices: a schedule hack or increased complexity and the public flag has basically no relevance. At this point I'd be even willing to reconsider the schedule hack because at least it's self-contained to a degree I guess? I'd even consider something like turning off sync entirely on the ruleset input manager after initial load or something over this if it doesn't incur further issues. |
Two things need to be clarified:
I've juggled and reordered the class around in hopes it reduces complexity. Take another look at it and see what you think. I have updated test coverage to reflect the new expected behaviour of the class, and tested on osu! to ensure it's working correctly. |
PassThroughInputManager
not sync new presses in Sync()
except for initial statePassThroughInputManager
to not sync new presses outside Handle()
I have removed the initial state synchronisation logic. Removing it does not regress the case brought in #1672 because scroll speed actions have been migrated to global key bindings, therefore not reading from the ruleset input manager to trigger the action. Also, if we compare this behavior on a normal Therefore, for the sake of reducing complexity and matching general behaviour of drawable input handling, I have removed it, and also confirmed all tests both on o!f and osu! are passing, all while the PR still maintains its original intent, which is to resolve ppy/osu#9658 (only partly). |
if (parentInputManager == null) | ||
return; | ||
|
||
var parentState1 = parentInputManager.CurrentState; |
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.
What's the point of this? I'm not really grasping why the existing parentState
above can't be used.
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.
Looks like a refactor error / me relying too much on Rider tools.
/// </summary> | ||
/// <param name="state">The state to synchronise current with. If this is null, it is regarded as an empty state.</param> | ||
protected virtual void SyncInputState(InputState state) | ||
private void syncIgnoredInput() |
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.
"ignored input" is a bit weird. I understand why you've named it that but perhaps just calling it "syncReleasedInputs" is better?
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.
Yeah I wasn't 101% sure about explicitly saying "released" since it contains code for updating joystick axes as well. I'll split it into two methods just so the purpose of the methods are still completely clear.
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 think this is fine.
When the game is paused, the game input manager has
UseParentInput
set to false for input to be frozen. When resuming gameplay in osu!, we ask the user to press a key at the location of the cursor first, then toggle backUseParentInput
and resume gameplay accordingly.If the user had paused without holding down any key, then when toggling back
UseParentInput
, either at the setter ofUseParentInput
, or at any subsequent update frames of the input manager, the key that was pressed to resume gameplay will be synchronised with the game input manager, causing gameplay to receive an incorrect press event and pollute the score for the player.This PR introduces a flag,
SyncNewPresses
, which can be disabled to prevent the above from happening, by makingSync()
not apply press input from parent state, and only look at releasing instead.