Change leniency of slider follow behaviour to better accommodate mistimed slider head hits

[isakvik]

With this discussion I'm addressing an annoyance with slider leniency, stemming from a slider's hard aim requirement of the cursor being inside the sliderball, as well as wanting to make the optimal strategy for keeping combo on certain maps not be in conflict with the accuracy requirement for sliderheads.

The sliderball requirement sometimes creates situations where the player assumes the sliderball is active when it's not (given they're trying to hit precisely, but was off by just enough to matter), which is pretty frustrating if it results in a miss for sure, but another reason to be more lenient with this requirement is that players realizing it works this way will be inclined to hit early on certain high SV sliders, or sliders with a tick/repeat just after the slider starts to make sure they don't break. Attempting to be on time should always be the best option, but right now this mechanic prevents that.

Early hit

Case: the player clicks a sliderhead early, and moves off the sliderhead to aim the rest of the sliderbody just before the sliderball appears
What happens: the sliderball never activates, and if the player does not notice this before the slider completes, they may miss a slidertick
Proposed change: the sliderball activates on an early hit as long as the player is still holding the button at the slider start timing, and will be active on start as long as the player is still inside the range of the slider follow circle

Late hit

Case: the player clicks a sliderhead late, and the sliderball is already outside of the sliderhead
What happens: the sliderball never activates, and the players would miss ticks before catching up
Proposed change: if the sliderball hasn't moved too far*, any sliderticks or eventual sliderend the sliderball has passed should be judged as hit, and the slider should now be active

*: if the player hits before the time the slider would spend covering the length of the followcircle radius. (this check prevents the catchup from applying to edge cases where the body exits the followcircle radius but the first tick is close)

The idea is the same as the early hit, but with a contingency for distance since you can't check directly for if the cursor is inside the sliderfollowcircle without introducing weird edge cases with repeats and sliders that curve back towards the sliderhead. Completing the sliderticks in case of a late hit is also vital to preserving accuracy as the best option.

This has been discussed by players who were asked about QoL changes to the game already.

[peppy]

I may agree with the early case, but late seems a bit weird to me.

Are you able to provide videos showing each of the cases (isolated with a test beatmap would be best) to better visualise?

[Zyfarok]

And yes @smoogipoo this seems mostly correct.

The only nitpick is that for late hits, it should NOT ONLY be within follow-radius units from the slider-start, but the ball should ALSO HAVE STAYED within follow-radius units since the start. Otherwise, on some weird slider-shapes (or fast repeats) where the slider-ball has the time to leave the follow-radius range and come back within the hit-window, it might be a better strategy for players to wait for the slider-ball to come back within follow-radius of the start before you actually hit the head, which would be a very weird behavior.

For the example of big black repeats, if you hit within the 50-hit-window and the repeat is less than follow-radius away from the head, then yes it makes sense to validate those repeat ticks.

[smoogipoo]

but the ball should ALSO HAVE STAYED within follow-radius units since the start

I'm having a very hard time understanding this. In particular I'm confused at the relevance of "the ball", because "the ball" is only tracking the centre of the follow circle, so it would already be a given that "the ball" is follow-radius units from the start if the follow circle itself is.
The slider ball is basically just the size and position of a deactivated follow circle. Though the concepts are linked in lazer, when I think of the slider ball I only think of the visuals that represent the centre of the follow circle.

Terminology is hard, which is why I've not referenced the slider ball in my above comment. I feel like I'm missing something here.

The way that I think about it is, conceptually it makes sense to me if no matter where on the start circle you hit; if you're within the follow circle's area at that point then the follow circle activates.
It's a bit of a deviation on the proposed idea of "if the follow-circle is within follow-radius units from the start then it activates" (as I understand it) that accounts for edge hits.

[osuKingling]

The reason the ball is specified is to handle cases where the ball itself leaves and re-enters the 'range' of the follow-circle.

Basically the ball should not only be within the radius but also have stayed within and not left it, as opposed to a 1 time check at slider-head hit time. The only reason this clause exists in the original proposal is to ensure ticks not inside the range are not counted if not aimed.

See this image: assuming the sliderhead hit is within the hit window, the first tick would not be hit even if the follow circle had moved slightly further and was within the head's hit range again as the player did not aim the tick and would incentivise players hitting late to not miss hard-to-aim ticks.

Hopefully this clarifies a bit @smoogipoo, but from my understanding it's just to counter rare edge cases like this

[isakvik]

With the late hit mechanics, how do you handle buzz sliders like those on big black which would allow 3 repeats to be passed before the hit window of the slider start runs out? Is this the exact case that you're trying to address?

Yes, for the case where the slider has no aim requirement. Holding your cursor in the same spot is trivial, but since trying to hit these on time could potentially break if you hit after the first repeat, accounting for this and hitting early is the obvious choice, right? If you hit outside the 300 range, though, slideracc would punish you for that, and The Big Black is not even the worst offender in this regard.

For the case where the slider has an aim requirement, Kingling's post explains the issue. Any slider where the body exits the range of the sliderfollowcircle radius from the head and then comes back within that range would be a problem with single bounds-check solution.

[Zyfarok]

In particular I'm confused at the relevance of "the ball", because "the ball" is only tracking the centre of the follow circle, so it would already be a given that "the ball" is follow-radius units from the start if the follow circle itself is.

@smoogipoo I'm sorry, I should have phrased it better. When I said "within follow-circle range" or "within follow-radius units", I was talking about the distance between two points: one is the center of the slider-head, and the other point is the center of the slider-ball (also center of the follow-circle). What I was trying to say is this distance should have remained smaller than the radius of the follow-circle at all time until the player hits the head late. (In other words, this means the center of the slider-head has remained inside the follow-circle at all time till the player's (late-)hit of the slider-head)

This simulates the slider-ball behavior as if the player did hit the slider at 0 offset and stayed in the center of the slider-head till that moment where the player actually hits the head late. This way, UNLESS the slider-ball has gone too far, the follow-circle remains active and the player can hit the slider-head late (within the 50 hit-window) without any other penalty than the slider-head judgement. Such a mechanic is necessary to avoid abuse of late-hits on some slider-shapes (like the one pictured in Kingling's message above) and repeats, as further detailed above.

I hope this clarifies everything ?

Other than that, two other considerations:

• Note that the results of the ticks that the ball goes through in that time-frame (when the player didn't hit the head yet) need to be buffered so that they can be either discarded if the slider-head is missed (we don't want to give free points for doing nothing) or otherwise validated in the correct order (after the head) if the player correctly hits the slider-head before the end of the hit-window.
• Also, one last thing we might want to consider is whether we add the additional requirement that the player cursor should be inside the follow-circle since the first tick, or just at each tick-timing, during that time-frame where the player didn't hit the head yet. This additional requirement would enforce the aim requirement of slider-ticks even if they are within the slider-head hit-window, but the tapping leniency would remain and the above slider-ball max distance requirement simply prevents any form of abuse.
  I don't have a clear opinion on whether this additional requirement is desirable, as the drawback is that it might make it necessary to aim the slider(-head) "not too late" and thus incentivize aiming early in general. This is really a question of how lenient do we want to be in that regards.

[bdach]

#24966 actually somewhat exacerbated issues with fast sliders (#25200 (comment)) and so maybe this is an escape hatch to fix it. Maybe. If I can understand the OP that is because I'm not sure I do and I've read it thrice.

[osuKingling]

#25129 (reply in thread) this may help

[isakvik]

It's not a direct response to the linked issue, but it's related in that following this proposal, slider judgements should allow hitting the head after the earliest ticks, as long as you're within the allowed timing window for the sliderheadcircle without punishment, as in having the ticks or the sliderhead miss and drop your combo (punishment for such a misinput would come in form of docked accuracy for the sliderhead outside the 300 window).

However, we need a contingency in the case of sliders that have a piece of their body outside the follow circle radius, but loops back and has their first tick close to the sliderhead, so that the aim requirement for this first tick cannot be skipped by simply hitting late. Something like this (Ocelot - KAEDE [Skystar's EX], ranked map):

Zyf's post here points out that this could be done by just continually checking for when the followcircle center actually exits the radius from the sliderhead, which is a bit more lenient than my proposal (checking for how far the followcircle has moved, and setting a limit based on that), but regardless of how this is done, it's for the purpose of preventing players from cheesing an aim requirement by hitting late.

I see #25218 addresses this by forcing a miss for the sliderhead in the case of a late hit. This just puts a hard limit on when you can click the sliderheadcircle, and given how scoring works in lazer, gives a pretty harsh penalty for late hits (even worse than stable!), something I want to remedy with this proposal for sliders with no, or very low, aim requirement exactly because slideracc already exists. As a player frequently annoyed by these limits on slider timing windows, I'd rather not get punished for trying to hit within the bounds that won't break my combo without needing to conform to arbitrary precision limits.

[bdach]

Something like this (Ocelot - KAEDE [Skystar's EX], ranked map):

I'm not sure what I'm even looking at there. What's the red thing? Can you show this using a different skin? Or give a timestamp for the slider?

I see #25218 addresses this by forcing a miss for the sliderhead in the case of a late hit. This just puts a hard limit on when you can click the sliderheadcircle, and given how scoring works in lazer, gives a pretty harsh penalty for late hits (even worse than stable!), something I want to remedy with this proposal for sliders with no, or very low, aim requirement exactly because slideracc already exists

What you have to understand there, though, is that due to how score V2 (and as such, current lazer scoring) works allowing different parts of the slider have overlapping hit windows - due to anomalies in accounting of the combo portion of score - can make it possible or impossible to reach 1M score, depending on the order in which the parts of the slider are judged. So there will be a penalty here either way, just a scoring-based one rather than a judgement-based one.

So the alternative there would be to accept that someone may not get max score on a map because they hit a very short slider late and ended up having the tail judged before the head and this is the only thing that prevented them from getting a max score. I'm not sure how much better or worse that feels from just having the head missed but in some ways you at least see a straight miss; you won't see that reordering issue while you're playing.

I guess what you could also do is have the slider not give any points until it's fully judged, and only then account points for it in some specified order? But that feels also weird and bad?

[isakvik]

Those are slider repeats. Timestamp: 01:22:910

I agree that scoring penalties from hitting slider judgements out of order is pretty bad, especially if invisible, but forcing a miss poses problems for maps with precision edge cases, of which there are too many to count (practically anything with 1/8 - 1/16 buzzsliders).

I guess what you could also do is have the slider not give any points until it's fully judged, and only then account points for it in some specified order?

Stable doesn't award any points for sliders with the combo factored in until the end, right? And still, any ticks hit award a little bit of score, just to make the player feel like they're hitting something. Couldn't the same thing apply here?

[bdach]

Stable doesn't award any points for sliders with the combo factored in until the end, right? And still, any ticks hit award a little bit of score, just to make the player feel like they're hitting something. Couldn't the same thing apply here?

You bring up a good point actually. stable does only grant the combo portion for 300s/50s/10s, and doesn't give any combo bonus for any ticks, repeats, tails etc., while lazer will. I'm not sure why that is? (for osu-stable-reference dwellers, compare treatment of the addComboMultiplier flag).

@smoogipoo Was this intentional or did we just all miss that? That sounds pretty key to scoring in general, this particular issue aside.

[peppy]

Taking a step back:

Based on the issue title and opening paragraph, it seems like the goal here is to appease those that are against slider head accuracy. I want to make it very clear that the changes proposed here are likely not going to help with that.

Both stable and lazer have the same hit windows for slider tracking mechanics already. The only difference is that in lazer you can get 50/100/300 equivalent judgements on the head instead of always 300. A miss of the head behaves in the same way on both versions of the game.

So all proposals in this thread, while on their own may be worth further investigation to make the game more approachable to players, do note that they are going to be increasing the lenience aka making the game easier than it ever has been.

@isakvik @Zyfarok can you confirm this is the intention here? If it is, then I think this issue needs to be renamed, and the opening post should be edited to make it very clear on the aim here.

[Bubbleman532]

The intention with the proposal isn't expressly to make the game easier, it's to deal with the edge cases brought up by incredibly short sliders ending before the end of the slider head hit window.

The behaviour of heads in stable on score v1 is such that if a slider would have a tick or repeat before the window for clicking a normal circle ends, you miss if you click too late - This behaviour was sub-optimal yet acceptable when sliderhead accuracy wasn't a thing, because you could just knowingly click early to avoid missing. Now that sliderheads have accuracy, this same "click-early" expectation doesn't fly, because you either risk a 100 judgement if you use the same strategy, or risk missing if you play the rhythm as-intended.

Sliders fast enough to raise this behaviour do already exist on ranked and loved maps.

[peppy]

Thanks for the clarification, that makes a bit more sense.

[isakvik]

So all proposals in this thread, while on their own may be worth further investigation to make the game more approachable to players, do note that they are going to be increasing the lenience aka making the game easier than it ever has been.

This is completely fine, because as stable and even lazer work now, even objects without aim requirements beyond "aim for the hitcircle" can have caps on their late hit timing windows (due to early sliderticks), and missing because of this is ridiculously annoying and even feels random if you don't know what's going on, even if everyone else experiences the same thing.

Slideracc makes the game harder, and that's fine; but let's not make the issue of missing leniency even worse.

[Givikap120]

Sliderhead behavior should fully match logical user expectation
If sliderhead has a window of 20ms before and AFTER start time, it means that clicking 19ms after 0 time should always result in a successful hit, no matter the length of the slider.
The behavior of hitting repeats and ends is more questionable
My opinion - if the slider is hit within 300 window - it should automatically auto-hit everything between the start point and 300 point if it was in the range of follow circles.
Otherwise you will have this very stupid stable-like behavior where players forced to hit buzz sliders early, what is very bad for a rhythm game.

[Zyfarok]

Yes but 1st, this can not be limited to the 300 window, and 2nd, if you do this without checking for the distance traveled by the ball, then you incentivize hitting late on some sliders, which we also want to avoid.
This is why I believe we need to check for either whether the ball is less than X away from the start circle or that the cursor was inside the follow circle all along. After more thought I think the second option ("cursor was inside") is simpler conceptually and to implement. It just means the slider-ball is activated at time 0 whether you did hit the slider-head or not yet, and stays active until you actually miss the head or exit the follow-circle (or have hit the head but released your key too early).

[Givikap120]

The 300 hitwindow was just an example
If I did understand you correctly, you basically said what I initially meant.
To confirm this I want to ask about this situation. Imagine there is a slider with repeat that's located 1px away from head and 5ms away from the start time of the slider. The player hit the slider really late so that cursor was not in the range of the slider follow circle at the time repeat was judged (5ms after start time). What will happen in that case? Sliderbreak or just meh judgement because of mistimed hit?

[Zyfarok]

it should be a hit on the tick.

the 2nd point I mention is about a slider where the slider-ball has already moved far away from the head (so if you had hit the head at time 0 and your cursor had stayed on the slider-head, the slider-ball would have deactivated since them) in which case hitting the slider late gives you the advantage of not needing to aim those ticks if those ticks are automatically completed on late-hits. This would be a problem.

[Givikap120]

okay, then it's like i said
in my initial message, I said that ticks are auto-completed only if they are in the range of the follow circle (from the slider head)

[Zyfarok]

Should work in most scenarios, but there's edge-cases where it's not perfect: if the shape is weird the ball could have gone away (so it would normally have been deactivated it) and then come back and in that case the slider-ball and follow-circle should only re-activate if your cursor passed on the ball itself (so, that's a smaller radius than the follow-circle).

[Zyfarok]

The main problem with slider-head leniency is the non-activation of the follow-circle in scenario where the player would expect it to be active, either because:

• the player did hit early and left the head (=ball) before the timing 0 but was still within follow-circle range.
• the player did hit late and the ball already started moving so he was not on the ball when hitting the head but was still within follow-circle range.
• same as previous (late hit) but additionally, the ball already passed through some ticks before the head hit. (e.g. fast buzz sliders)

So I believe the two simplest yet reasonable fix should be as follows:

Solution 1

When one of the following two events happens, the slider-ball is activated (follow-circle "deployed"/active) :

• Correct hit of the slider-head
• Timing 0 of the slider-head (when the ball starts moving)

In both case, the slider-ball and follow-circle should only be activated if the cursor is within follow-circle range (no need to aim the ball), and it is disabled as soon as the cursor leaves the follow-circle range as expected. However, the biggest change is that until the slider-head is hit, the slider-ball stays active even if the key is not pressed, but as soon as the slider-head is hit (or missed) the requirement of holding the key starts.

Solution 2

Before the hit (or miss) of the slider-head (or alternatively until the end of the hit-window no matter what ?), the follow-circle remains active at all time and ticks are validated if the cursor is inside it. That is, you don't need to pass on the slider-ball to reactivating it, just entering the follow-circle again is sufficient. Similarly as Solution 1, as soon as the slider-head is hit/missed the requirement to hold the key starts and the slider-ball and follow-circle starts behaving as usual again.

Common to both: Judgement order

In both solutions, it is required to make sure that judgements are still applied in order. Thus, any slider-ticks validated before the head hit/miss has to be buffered. This adds complexity but is necessary to cover the full spectrum of scenarios.
If the head is missed, what is decided to be done of the buffered judgement does not really matter much, but the most reasonable seems to drop them (unless the key is being hold ?).
If this is too complex, it might be ok-ish to force the hit-window to end before the first slider-tick and it will work fine in most scenarios but this will affect some maps negatively. (again, the example of fast buzz sliders)

Final note: The only "issue" of those solutions is that there are some scenarios where it might be better to hit late (except Solution 2 if keeping the follow-circle "active" till the end of the hit-window no matter what), but this would be so very edge-case (specific shapes of fast sliders) and hard to perform in practice that it can be reasonably ignored.

[peppy]

As an update, this change will be implemented fully in the next release (#25748 and #25776). Please make sure to give it ample playtesting over the coming weeks.

[Zyfarok]

Thanks for the update, this looks very promising.

[Givikap120]

Very good gameplay changes, thanks