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

Drain level does not match stable #7975

Closed
MTGPROD opened this issue Feb 23, 2020 · 36 comments · Fixed by #18340
Closed

Drain level does not match stable #7975

MTGPROD opened this issue Feb 23, 2020 · 36 comments · Fixed by #18340

Comments

@MTGPROD
Copy link

MTGPROD commented Feb 23, 2020

Describe the bug:

When a map have hp drain 6, just some 100 and 50 can drain a lot of hp. After that, just one miss and you lost. In osu stable it's not hard at this point.

Screenshots or videos showing encountered issue:

https://youtu.be/vaOy9Dgqt2A

osu!lazer version:

2020.221.0

Logs:
please attach logs here, which are located at:

  • %AppData%/osu/logs (on Windows),
  • ~/.local/share/osu/logs (on Linux & macOS).

I'm on android

@bdach bdach changed the title Hp drain 6 is broken Drain level does not match stable Feb 23, 2020
@bdach bdach changed the title Drain level does not match stable Drain level too high / does not match stable Feb 23, 2020
@bdach
Copy link
Collaborator

bdach commented Feb 23, 2020

Raised as a concern before (#7606), was never reopened as a separate issue about the drain level itself (draining after break is tracked in #7607). Renamed for better searchability (not that I advocate for completely reverting to stable algorithm, maybe slightly less harsh drain will be ok too).

@MTGPROD

This comment has been minimized.

@MTGPROD
Copy link
Author

MTGPROD commented Feb 23, 2020

Especially since I speak well of hp drain 6 in particular because I tested scarlet rose which has 7 hp drain and I lose much less hp when you have a 100, 50 or miss (When I was around 75% and I had a lot of miss and well a 300 gave much more hp than hp drain 6). The problem is more complex

@FAB1150

This comment has been minimized.

@ghm12

This comment has been minimized.

@bdach
Copy link
Collaborator

bdach commented Feb 24, 2020

Please refrain from posting "confirmation / +1" comments as they don't really bring in much value - you can use comment reactions as means of support instead. We are well aware that the current drain algorithm is not exactly as was in stable and it was a conscious decision at the time of re-adding it. Suggestions on what should be done to change this situation are however welcome.

@mcendu
Copy link
Contributor

mcendu commented Feb 25, 2020

Instead of using the lowest percentage attainable during a perfect play, I propose that the lowest percentage during the worst possible no miss play (or slightly harsher like all 100s) should be used to determine the drain rate. This can make the drain more relaxed.

@MTGPROD
Copy link
Author

MTGPROD commented Feb 25, 2020

The 2020.225.0 update seems to fix the problem. It's your turn to test

@bdach
Copy link
Collaborator

bdach commented Feb 25, 2020

@smoogipoo
Copy link
Contributor

smoogipoo commented Feb 26, 2020

I'm going to keep this issue open until people are satisfied with the HP drain.

@mcendu using the worst possible play will make HP drain significantly more lenient, which isn't what we're aiming for. We want the drain rate to be rougher in these higher HP maps (HP>5); HP6 results in a minimum HP from drain of 62%.

The PR above raises the amount of HP awarded for GOODs from 1.5% to 2.5%, without lowering the drain rate.

@MTGPROD
Copy link
Author

MTGPROD commented Feb 26, 2020

So, if we make a 50. what happens? @smoogipoo

@smoogipoo
Copy link
Contributor

smoogipoo commented Feb 26, 2020

Currently, HP is decreased by 0.25%.

protected virtual double HealthIncreaseFor(HitResult result)
{
switch (result)
{
case HitResult.Miss:
return -DEFAULT_MAX_HEALTH_INCREASE;
case HitResult.Meh:
return -DEFAULT_MAX_HEALTH_INCREASE * 0.05;
case HitResult.Ok:
return -DEFAULT_MAX_HEALTH_INCREASE * 0.01;
case HitResult.Good:
return DEFAULT_MAX_HEALTH_INCREASE * 0.5;
case HitResult.Great:
return DEFAULT_MAX_HEALTH_INCREASE;
case HitResult.Perfect:
return DEFAULT_MAX_HEALTH_INCREASE * 1.05;
default:
return 0;
}
}

@ppy ppy deleted a comment from MTGPROD Feb 26, 2020
@MTGPROD
Copy link
Author

MTGPROD commented Feb 26, 2020

But, what is HitResult.Ok it is for mania/taiko or something ?

@MTGPROD
Copy link
Author

MTGPROD commented Feb 26, 2020

From hp drain 6 it's much more playable than before. Thanks @smoogipoo

@MTGPROD
Copy link
Author

MTGPROD commented Feb 26, 2020

But for specific maps that's very hard like before...

@aemino
Copy link

aemino commented Mar 3, 2020

I hope this anecdotal case is all right to post here, apologies if not. I was playing this map on master and maintaining ~91-92% accuracy for the first minute, but my HP slowly dropped, leading to it bouncing around 20% by 1 minute in. This meant that when I hit two "meh"s within a small timespan I instantly failed the map with 92% accuracy.

I notice similar behavior with other maps too; some maps (due to the spacing of notes or BPM?) tend to have cases where your HP can drop to a very low percentage and then not recover while maintaining a "local" accuracy of >90%. Is this desired behavior?

@whizvox
Copy link

whizvox commented Mar 5, 2020

leaving my own anecdotal case as well

https://youtu.be/oJKFkNtdbNc

way too easy to fail the map (with DT and HP 6) towards the end of the chorus, struggle to get above half health the entire time despite maintaining a ~94% accuracy. I managed to lose about a quarter of my health in the ~1 second space between the end of the break and the next note. I instantly fail upon missing a note 58 combo later.

using the newest 2020.229.1 release for windows 10

@bdach bdach changed the title Drain level too high / does not match stable Drain level does not match stable Mar 6, 2020
@bdach
Copy link
Collaborator

bdach commented Mar 6, 2020

Generalising this as drain has now been called both too harsh and too lenient, so clearly the user expectation is that drain will be exactly the same as stable (which, to emphasise, it might not necessarily end up being).

@whizvox
Copy link

whizvox commented Mar 6, 2020

no, drain just doesn't make sense and is inconsistent when comparing theoretical vs. actual drain.

in my previous post, I demonstrated an instance where drain was way too high with a map with HP6 and OD7. here's an instance where drain is too low in comparison.

https://www.youtube.com/watch?v=NSTHwT5ntAA

notice that the map is HP7 and OD7.5, but even after intentionally not playing for a second or two, the HP bar doesn't even go below the halfway point.

how can both the HP and OD values be higher, but in gameplay, the drain and HP reduction be much, much lower?

@bdach
Copy link
Collaborator

bdach commented Mar 6, 2020

I'm not sure what "theoretical drain" is supposed to mean but sure. I have a slight feeling the other mechanical changes (like removing sliderend leniency) could have a knock-on effect on how drain feels (since it's based on percentage of HP on a perfect play) but I have no concrete evidence to back that claim up at this point.

@huupoke
Copy link

huupoke commented Mar 7, 2020

And I don't think there should be passive drain: https://youtu.be/Wyc-vVYsGOo

@bdach
Copy link
Collaborator

bdach commented Mar 7, 2020

@huupoke12 see discussion at #7370.

@iSimpFor
Copy link

i feel as if on hp10 in its current state that goods and mehs give too much hp and allow the user to survive hitting a lot of goods and mehs
i think hp drain should be lessened a bit and goods and mehs should have a slight nerf in amount of hp given

@iSimpFor
Copy link

after more testing, i think it's more of a problem on high density maps since there's way more opportunities to gain hp
since lazer can detect note density, maybe we should use that to adjust hp so that high density parts have harsher drain and lower density parts have lesser drain

@iSimpFor
Copy link

testing in mania with a hp7 map, poorer judgements give too much hp in the more dense sections to the point where it overrides all the misses you will get and it allows you to survive by getting 55% accuracy which allows mashing for hard passes you shouldn't get

adjusting/accounting for the previous 2 comments i made, in all modes expect taiko:
hp should account for map section density to increase/decrease hp accordingly
hp drain should be nerfed somewhat to prevent draining to 0 in low density sections
the good, ok, and meh judgements should give less hp to prevent poorer accuracy from passing through

map i used for testing: https://osu.ppy.sh/beatmapsets/1034114#mania/2162156

@RaskiTech
Copy link

RaskiTech commented Oct 10, 2021

I haven't noticed any problems recovering, but the HP definitely is way more lenient than in stable. I downloaded lazer and stated to easily beat maps I couldn't beat in stable.

I made a 10 second video showing that: with not hitting anything lazer makes it ~twice as far as stable. https://youtu.be/C8ivPJ4ouo8
This of course is a preference, but I would highly prefer the original. In lazer you can get down to 60% accuracy and still easily beat the map, whereas in standard maps that is almost impossible in stable.

@Balcke
Copy link

Balcke commented Apr 18, 2022

Imma just leave my hp issue here
https://youtu.be/2JLs44a-NQs
5.2 hp drain, 95% accuracy. 2 misses and you're dead.
Same map on stable
https://youtu.be/R8UxJGYz6vY
Same hp5.2, 90% accuracy. 9 misses and im somewhat doing just fine.
There is also a map (R-P-G by AirinCat) on lazer that even with sumn like 89% acc i still die with hp5. But on sumn like Whatever I Do by Nhawak with hp 7 with a purposely bad play (75% acc, 31 misses, 5*) i survive just fine

Edit: i tried hp 7 (diff adjust) on AaAaAaAAaAaAAa and i somehow survived with 94% acc 3 misses. There might be something with hp5-6 that made it hard for me idk.
Edit: its pure dumb luck.

@ghost
Copy link

ghost commented May 5, 2022

I've run into an HP-related issue on a newly ranked map: https://osu.ppy.sh/beatmapsets/1694155#osu/3474143

On lazer it becomes practically unpassable -- I suspect that is due to the lack of geki/katu. I have to play very precisely just to keep my HP from draining, and every miss is very punishing.

lazer-comp.mp4

Turning on classic (which I hope sufficiently emulates stable) makes the difficulty much more reasonable, and even allows me to recover from deliberately missing several notes in a row.

classic-comp.mp4

While classic mod is a reasonable workaround for older stuff that relies heavily on the HP model as it is in stable, as a player I would expect any map that gets ranked today to be completely playable in nomod. On the other hand I've seen 7*+ maps that I can first try on lazer, while a more skilled player cannot pass them on stable (namely https://osu.ppy.sh/beatmapsets/1392496#osu/2874944)

I don't have a solution to propose, but the current state doesn't seem very sustainable if both stable and lazer are to be maintained going forward, especially once score submission kicks in.

@huupoke
Copy link

huupoke commented May 6, 2022

Well, I think the game shouldn't "break" maps by default. New players would be confused of why the same map is different in stable and lazer.
I would propose a solution:

  • For maps created in stable, mark them as "Legacy map" in lazer.
  • For maps created in lazer, make a checkbox to use the "Legacy format/Compatible format" in the editor by default (for now, until lazer replace stable for some time). "Legacy map" can be played in both stable and lazer.
  • Make an indication for legacy maps (same as map status (ranked/loved)) on the map selection screen.
  • Stable can't import (or make it can play but unranked) "New format/Lazer format" maps.
  • By default (no mod), legacy maps use legacy (stable) mechanics (game play, PP, score, ...), lazer-format maps use the new mechanics.
  • Players can choose to use classic mod on lazer maps and "lazer" mod on legacy maps.
  • If using legacy mechanics, make the leaderboard and mod combination/multiplication as the stable (combined leaderboard for all mods; can't customise mods; new mods introduced in lazer can't be selected or make it unranked).

@jedel1043
Copy link

jedel1043 commented Jul 24, 2022

I'm pretty sure this still needs a bit more work. If you compare https://osu.ppy.sh/beatmapsets/480765#osu/1169864 with https://osu.ppy.sh/beatmapsets/991300#osu/2496646, lazer tends to drain HP in jump maps very heavily, while on stream maps you can even spam and easily pass a map, and those have the same HP drain!

On stable, notelock probably took care of that by punishing misses within streams, but knowing this doesn't exist in lazer, it would need to adjust HP drain to consider this...

@frenzibyte
Copy link
Member

Open a discussion thread please.

@jedel1043
Copy link

Open a discussion thread please.

There's already #17912, I think. I just wanted to bump this since it apparently was already fixed but the problem persists.

@Kyuunex
Copy link

Kyuunex commented May 23, 2023

I found a map that has much worse hp drain in lazer (with and without classic mod) than in stable. https://osu.ppy.sh/beatmapsets/469782#osu/1004556

im bringing this up as my assumption for the classic mod was it's as close to stable as it gets and was told to leave the link in this thread.

@smoogipoo smoogipoo reopened this Sep 19, 2023
@smoogipoo smoogipoo moved this from Needs discussion to Needs implementation in Path to osu!(lazer) ranked play Sep 19, 2023
@smoogipoo
Copy link
Contributor

I'd love to avoid re-implementing osu!stable's HP calculation given that it also has issues that are worked around by the whole not-being-able-to-die-until-you-miss thing, but it may be the path of least resistance.

Probably need some quick investigation into the issue here, and brainstorming for possible solutions that aren't re-implementing osu!stable first.

@smoogipoo smoogipoo moved this from Needs implementation to Needs discussion in Path to osu!(lazer) ranked play Sep 19, 2023
@bdach
Copy link
Collaborator

bdach commented Sep 19, 2023

@smoogipoo #24365 was already on the project. Seems like we should probably keep just one.

@smoogipoo
Copy link
Contributor

Ah yep, my bad. Had this one sitting in my inbox for a few months...

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

Successfully merging a pull request may close this issue.