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

Swells in osu!taiko are cheeseable by binding don and kat to same key #24780

Closed
peppy opened this issue Sep 11, 2023 Discussed in #24763 · 2 comments · Fixed by #25152
Closed

Swells in osu!taiko are cheeseable by binding don and kat to same key #24780

peppy opened this issue Sep 11, 2023 Discussed in #24763 · 2 comments · Fixed by #25152

Comments

@peppy
Copy link
Sponsor Member

peppy commented Sep 11, 2023

Likely needs to be fixed.

Discussed in #24763

Originally posted by Non-Binary-Programmer September 9, 2023
If one key is bound to both a rim hit and a center hit, then hitting that key will always advance a spinner by two keypresses. The most practical way to do this without external programs would be to bind the built-in second input for the left side center and rim inputs to the same key, and use the remaining 4 inputs regularly. This might be problematic, but doesn't give an advantage over someone who can properly alternate dkdk with both hands. However, by using external programs, or by sacrificing your regular inputs for the right side center and rim, you can hit all four with one key, allowing you to advance the spinner by 4 hits with one keypress, and generating a major advantage.

Is this intentional?

@bdach
Copy link
Collaborator

bdach commented Oct 4, 2023

I looked at what stable does to curtail this, and as far as I can tell, it:

  • Disallows being able to bind multiple keys to same binding
  • Due to the nature of how stable appears to handle input (InputManager setting input flags are updated once per game update loop, and then read once per frame by gameplay components), you can't trigger more than one swell tick per frame
  • There's also... this code:
            // punish if less then 30 ms has passed since the last invalid button
            // ignore if we are in relaxmode
            if (((AudioEngine.Time - lastInvalidButtonTime) >= 30 || Player.currentScore?.Processor != null) && !Player.Relaxing)
            {
                // Only increase if you alternate.
                // We start with lastButton=0 so the user can choose
                // the first note to begin to alternate with.
                if (hitRed)
                {
                    if (lastButton != red_Button)
                    {
                        increase = true;
                        lastButton = red_Button;
                    }
                    else
                    {
                        if (Player.currentScore?.Processor == null)
                            lastInvalidButtonTime = AudioEngine.Time;
                        return IncreaseScoreType.Ignore;
                    }
                }
                else if (hitBlue)
                {
                    if (lastButton != blue_Button)
                    {
                        increase = true;
                        lastButton = blue_Button;
                    }
                    else
                    {
                        if (Player.currentScore?.Processor == null)
                            lastInvalidButtonTime = AudioEngine.Time;
                        return IncreaseScoreType.Ignore;
                    }
                }

            }

(src: https://github.com/peppy/osu-stable-reference/blob/3ea48705eb67172c430371dcfc8a16a002ed0d3d/osu!/GameplayElements/HitObjects/Taiko/SpinnerTaiko.cs#L206-L242)

It appears to be anti-cheese protecting against spamming keys too much, wherein repeated presses of an invalid key closer than 30ms cause input to be blocked to the swell altogether - but the weirdest part about it are the Processor == null checks, which in stable basically boil down to "this is only enabled when score V2 is off". So while the rest is rather obvious, I'm not entirely sure what to do about that part...

@bdach
Copy link
Collaborator

bdach commented Oct 5, 2023

#25010 was the immediate fix here, but I still want to go back to this and for one disallow the ability to bind multiple ruleset bindings to one physical key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants