Make bananas not affect hyperdash state in the osu!catch ruleset#38091
Make bananas not affect hyperdash state in the osu!catch ruleset#38091TomyDoesThings wants to merge 3 commits into
Conversation
OnNewResult receives a single hit object and so when speaking about the handled hit object, it should be talked about as singular just like the original note.
|
@peppy Please advise what is to be done with this PR and other aspire-adjacent fixes that may arrive in the near future. With the recent announcement of a new aspire installment questions are already being asked on the news post as to whether lazer is going to bring back behaviours that aspire maps of yore depend on. I was of the impression that bringing back behaviours exploited only by aspire maps was not a priority for the lazer client but opinions may have shifted since. |
|
Regarding this PR:
Regarding Aspire:
I've been very clear about nothing being guaranteed to work for aspire. There's a disclaimer in the news post. There's no guarantees that behaviours used in the contest will remain working. Users looking to abuse broken game mechanics should most definitely reach out for confirmation if they don't want their maps to break in the future. We are not holding ourselves to keeping broken behaviours "because aspire". |
|
On new result meaning: It refers to the method OnNewResult that is called whenever a note is caught or missed. The method is called each time that happens and it does run some logic regarding the catcher's hyperstates. Why the Aspire specific: Logically, both tiny droplets and bananas under no circumstance are hyper, ever. Only droplets and fruits do this, yet, the line of code in question allows for accounting for if a banana may be hyper, ironically in if there is an Aspire pattern. But the else statement will always trigger putting the catcher in a default movement state each time a banana is caught or missed. The reason I say Aspire only is because on non-Aspire maps, the hyper fruit and hyper target will always be before or after bananas, never during. Each banana sets the catcher to a non-hyper state, and that remains invisible on non-Aspire maps because no other fruit or droplet can coexist during a banana shower. Tiny droplets mandatorily were and are accounted for, since they appear between droplets and fruits which would mean it'd affect non-Aspire gameplay. The hyper speed has to be maintained throughout the whole juice stream provided by the previous hyper fruit. Why is stable more correct here: As I said, the normal behavior is only fruits and (not tiny) droplets are capable of affecting the catcher's hyperdash state. It's a clean definition. You have the note that puts the catcher in a hyperstate and the note that puts the catcher in a non-hyper state regardless od what happens in between. Only fruits and (not tiny) droplets control the catcher being hyper or not. With this, it'd be more efficient in code to just state that directly with an early return instead of each and every banana checking for if the banana's start time is the previous hyper's start time (it never is unless maybe incredibly lucky considering bananas auto-generate), checking if the banana was hit/caught (okay) and checking if the banana has a hyper dash target (it will always be null), and then going to the else statement and setting the catcher to non-hyper. It just seems convoluted for what seems to be no reason. Bananas should just also be ignored when it comes to hypers. After all, the note gives the impression only tiny droplets has no effect on hyperdash states. Is there any reason why bananas would also have the role of affecting hyperstates when they never are a hyper themselves and are never a hyper target either? The explanation in the current code implies only tiny droplets are excluded in hyperstate updating, but bananas never are involved in being hyper or a hyper target, bananas are fully disconnected from this as well. |
|
Even in initializing hypers, bananas alongside tiny droplets are ignored, so actual gameplay should too, otherwise what the initializer calculates which does affect SR will be inaccurate (hyper ending earlier meaning increased precision or impossible fruit to catch being ignored). osu/osu.Game.Rulesets.Catch/Beatmaps/CatchBeatmapProcessor.cs Lines 212 to 216 in 285adcb |
|
Wait... normal maps could actually be affected. I need to test something. This may even already exist in at least some converts or ranked maps. If a hyper fruit appears before a banana shower and the target hyper fruit is after the banana shower, then... the bug applies here too. A seemingly ranked pattern becomes broken or impossible. The bananas would for sure be disruptive with making the catcher become hyperless prematurely. |
|
@peppy and @bdach, well then, I did not think of it because this is probably at least somewhat rare for somebody to map, but this bug can actually happen in ranked maps that don't have hit objects occurring at the same time. Please take a look. uh_oh_non_2b_banana_blocking_hyper.mp4Here is the exported map (GitHub doesn't allow osz, so I compressed it into a zip) though it could easily be replicated: Now this bug is actually a bit more concerning. I tested this pattern in osu!stable as well and bananas do not cancel out hypers in osu!stable in a pattern like this either. |
|
yes, that's what i said in my initial reply |
Whoops, my bad then. I kind of hyperfocused on the Aspire case since I think it is where the issue would most prominently occur. I did not think of the hyper fruit -> banana shower -> target fruit pattern until a bit later. I guess the note describing the behavior in this PR should be adjusted then since it is not an Aspire only thing. I am confused though on what you mean by "inline command". |
|
Anyhow, a hyper turning out to be a dud I'd say is unnatural osu!catch gameplay. Matching osu!stable to have this not happen would be better, in replays between stable and lazer, to be in line with how hypers are initialized and what SR sees from hypers, and for more natural gameplay, to not surprise the player that the hyper just suddenly shuts down as if something went wrong. It certainly caught me off guard. |
|
Just so none of us forget, I'll adjust the note to not say it is specifically for Aspire. Bananas should not affect hyperdash state. That is the fundamental natural behavior. I just wanted to without a doubt also prove the current unnatural-feeling banana logic is visible and feelable to the end user both in Aspire and normal gameplay. |
|
inline command -> inline comment, was an autocorrect typo sorry. |
"Fundamental" to you maybe. As the game designer, I'd expect the catcher to never be in hyperdash during a banana shower/spinner. If hyperdash is required after the spinner, i'd expect it to be restored. |
Yeah, sorry, maybe there is another way. I'll go over my logic on all this here.
So there would be a dynamic-speed-given-distance-to-next-fruit hyper restoration done to the catcher right when the banana shower ends to ensure they can reach the fruit after? And this would only happen when the fruit right before the banana shower is hyper? Normally, a hyper indicates continue to where the next fruit or (not tiny) droplet would be no matter what even if offscreen, otherwise a miss will for sure occur. Even if the player does not see a fruit or (not tiny droplet) after a hyper, they know to dash towards its direction. It implies that without that fruit being a hyper, the next note is impossible to catch. Except, the next note seems to be a banana. Is the player to briefly catch bananas in the banana shower then remember to resume hyper dash right after, or ignore the bananas and keep dashing towards the next fruit? When exactly would the hyper be paused briefly then restored? I guess probably paused on banana shower entry and restored on its end. Tiny droplets while they do not affect hyperdash state are part of the direct path given by fruits and droplets. Bananas have no direct path, just a general optimal path, so it giving the catcher a hyper hyperdash state back would have to be dynamic if the catcher is to spin or catch bananas optimally briefly. But how about spinner traps? More specifically:
If spinner traps are to still exist (spinner traps kind of suck though, but are there), then banana showers themselves cannot directly be the ones to provide a hyper, so it could only be the fruit before the banana shower doing this, otherwise the most optimal banana path would transform being kind of unfair to beatmaps' leaderboards. And if the fruit right before a banana shower is hyper, what purpose does it serve in giving extra speed? Is it for the first banana in the banana shower or the note after the spinner, or would it just be a visual cue? The simplest and safest option, even though unintended since this current unintended behavior is definitely an edge case, is to continue with what osu!stable does for this: have bananas not affect the hyperdash state. The edge case is pretty rare I'm guessing and I think the risks of refactoring so much for just this specific case outweighs a brief breakage of the original intention. With just non-Aspire alone, dynamic speed calculation would already have to be considered. It's much stabler to have all fruits have a predetermined pre-set constant speed and have the case of what if Aspire rather than to also include dynamic speed for this specific edge case and have the case of what if Aspire. |
|
It is also worth mentioning that hyper notes and their targets are always notes that provide combo. Bananas and tiny droplets do not provide combo, and bananas also do not provide accuracy. |
|
My more direct and overall conclusion: Please keep in mind that this simple addition to not have bananas affect hyperdash state at worst just makes osu!lazer match osu!stable in this regard. I think it'd be better than certain rankable or ranked maps having an impossible to catch fruit if doing a full combo which would make a full combo impossible all because a banana shower occurred between a hyper and its target, which can happen in regular gameplay. If not this fix of It's one of those moments where a ranked map would only be able to be full combo'd in osu!stable over this one very minute difference. And as I mentioned, a banana shower cannot reliably provide a hyper (or even teleportation to the next fruit) without voiding other humanly best scores, because a spinner or banana shower you spin the best as possible on but not too much to the point you miss the next note or fruit. A hyper banana would void that rule by providing a catcher way to negate that penalty that has stayed in osu!standard (besides Aspire invisible spinners in osu!stable, but you know what I mean) and osu!catch. If still banana showers should provide a hyper, that is a huge rework leaderboard-humanly-best score, star rating, and movement wise all for this one specific case. I understand that this specific behavior may suck to see with how it deviates from the vision you've had for osu!catch, @peppy, but at least it is a behavior that is rare to see in action and this simple fix would be the stablest least-huge-rework solution we have. |
bdach
added
the
subjective
|
I've downloaded... pretty much almost the entire Ranked section for osu!catch and ran a local script that checked for maps affected by this. The list goes:
There are 12,769 Ranked and Loved maps osu!catch specific maps combined (not mapsets, seperate difficulties) and I have 11,966 Ranked and Loved maps combined, meaning only 803 maps that did not go thorugh the check. |
4 participants
Note: This bug can actually affect non-Aspire maps if a hyper fruit appears before a banana shower and its hyper target is the fruit after the banana shower!
uh_oh_non_2b_banana_blocking_hyper.mp4
With the Aspire event coming back after like 6 years, I'd say this bug I am reporting here and its fix is quite urgent for osu!catch Aspire maps especially if done early in the case somebody is considering using this as a gimmick whether accidental or not. If this fix is not applied, hyper fruits will continue to not match in certain Aspire maps between osu!stable and osu!lazer, and this can possibly have unintended consequences during voting when both osu!stable and osu!lazer players have played with fundamentally different hypers.
Here are GIFs somebody provided to me showcasing the issue.
osu!stable - bananas right as they are caught or missed do not forcefully unhyper the catcher before the hyper target:
osu!lazer - bananas right as they are caught or missed do forcefully unhyper the catcher before the hyper target:
Bananas have the power to stop the catcher from being hyper if they are caught or missed during a section where the catcher is to be hyper until the hyper dash target is caught or missed. As I catch the hyper fruit and am dashing to the next fruit, as soon as the banana is caught or missed, the catcher returns to a default hyperless state prematurely, and I'm not able to use the hyper from the hyper fruit in full. It can make the next fruit impossible to catch meanwhile in osu!stable, there is no problem.
I believe osu!stable's behavior regarding this is preferred.