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

Adjust HP drain and recoveries to closer match osu-stable #18340

Merged
merged 3 commits into from
May 23, 2022

Conversation

smoogipoo
Copy link
Contributor

@smoogipoo smoogipoo commented May 20, 2022

I've gone through the osu-stable implementation once again and found a few areas of improvement.

My testing was mostly done on https://osu.ppy.sh/beatmapsets/268431#osu/611157. I don't have comparisons because they're kinda hard to make and there's still differences (see my conclusions).

Minimum health targets were incorrect

The original values weren't taken from stable, but rather "what feels ok". As it turns out, all of osu+catch+mania use the same HP targets, albeit mania doesn't have HP drain.

Of particular importance, stable has 3 target values:

lowest-hp-ever: [ 97.5% 80% 30% ]
lowest-hp-combo-end: [ 99% 85% 40%]
lowest-hp-end: [ 99% 90% 40% ]

These values are checked at different points in the calculation to make sure the HP doesn't fall below it. Since lazer doesn't have geki/katsu, the second row wasn't considered, and I've decided to go with the hp-end values from above purely because they feel a little bit better in actual gameplay.

Adjusted HP increases to line up better

From the very start of implementation of HP drain, lazer's Meh judgements decreased HP. I can't find any reason for this, so I take it as my misunderstanding at the time that 50s decrease HP in stable, but this is not the case.

Additionally, misses are also quite harsh on stable and quite lenient on lazer. I've tried to make misses a little bit more harsh while hopefully not impacting lower-HP values too much.

The following is a table of stable vs lazer HP increases as percentages of total HP for each hit result. A linear interpolation of the HP difficulty value is indicated in cells containing multiple values within brackets.

result stable stable (HP7) lazer (master) lazer (new)
great 3% 3% 5% 5%
ok [ 8.8% 1.1% 1.1% ] 1.1% 2.5% 2.5%
meh [ 1.6% 0.2% 0.2% ] 0.2% -0.25% 0.25% ⬆
miss [ -3% -12.5% -20% ] -15.5% -5% -10% ⬇
l_tick_hit 1.5%* 1.5%* 5% 5%
l_tick_miss [ -2% -7.5% -14% ] -10.1% -5% -5%

* repeats give 2% HP but lazer doesn't differentiate

Note: The above are the base values pre-hp-multiplier (determined as part of osu-stable's HP drain algorithm). I don't think this multiplier makes much of a difference in practice.

Conclusion

It's still not perfect and definitely doesn't match osu-stable, but feels better at higher HP values. I'm still interested in trying to keep it simple before resorting to outright porting osu-stable's implementation across; interpolation, multipliers, and all.

@Morilli
Copy link
Contributor

Morilli commented May 20, 2022

Hm. The map I was most interested in seeing the difference in was this one, which has seen a clear improvement in playability but still remains unplayable to me, while there is no issue at all in stable (and I don't think there should be at the HP level of 7).

It seems that HP values scale vastly differently at 5+ vs. below 5 now, which may "hide" any issues at an HP rate near 5, while being much more visible at higher values. For example, Difficulty Adjusting the HP value of the map you linked to 8 shows that the first time HP can be "gained", aka 100% health is reached for the first time after the beginning, is at 1:05, which means any inaccuracy in the first minute of the map is "permanent".

Copy link
Member

@peppy peppy left a comment

Choose a reason for hiding this comment

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

Haven't tested this, but seems sane to get out to the wider audience for further testing

@peppy peppy merged commit 87947c6 into ppy:master May 23, 2022
@smoogipoo
Copy link
Contributor Author

@Morilli I didn't intend to touch upon that in this PR, only improving the harshness of it. I think such considerations probably need an overhaul of the entire processor.

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

Successfully merging this pull request may close these issues.

Drain level does not match stable
4 participants