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

osu!catch SR rebalance proposal #88

Closed
Sorceress4628 opened this issue Mar 4, 2019 · 11 comments
Closed

osu!catch SR rebalance proposal #88

Sorceress4628 opened this issue Mar 4, 2019 · 11 comments

Comments

@Sorceress4628
Copy link

Sorceress4628 commented Mar 4, 2019

I originally wrote about some possible changes to catch SR back on the forums around 2 months ago, now with catch on lazer shaping up we can see how these changes actually look.

I'm a total gitnoob and I'm no programmer either so I've included the code I have below, if anyone can assist with sorting out a PR that would be a huge help.

Movement.cs
CatchDifficultyCalculator.cs
CatchDifficultyHitObject.cs

If anything in this post contradicts the code, then the code is correct and the post is wrong

Edge Dash Bonus

Quick note on what an edge dash is for those unfamiliar with this terminology. An edge dash is when the distance between two notes is very close to triggering a hyperdash, requiring the player to use the edges of the catcher to be able to catch the fruits. The precise movement and timing required makes these dashes fairly tricky.

Edge dashes have been undervalued in SR for some time. Thankfully an edge dash bonus already exists so it can just be increased a fair bit. The bonus is also scaled by strainTime, reducing the bonus at lower ms values where edge dashes are actually easier as the hyperdash generation threshold is more lenient. The proposal also increases the distance at which a dash is considered an edge dash as it seems a little too strict currently.

Live
Bonus = 1.0
Edge dash threshold = 10

New
Bonus = 5.00
Edge dash threshold = 14
Edge dash speed scaling = Bonus * (Math.Min(catchCurrent.StrainTime, 180) / 180)

This gives a significant increase to SR on beatmaps with edge dashes, most notable on converted beatmaps.

Hyperdash Bonus Removal

There currently exists a bonus for hyperdashes and edge dashes on a direction change. This bonus does very little for edge dashes yet has a significant impact on hyperdash heavy beatmaps, most noticeable on Overdose (Extra) level Specifics.

This proposal removes this bonus, leaving edge dashes to be handled solely by the other edge dash bonus.

As for hyperdashes, no bonus seems necessary. Whilst difficult for newer players, hyperdashes are trivial at higher skill levels and the difficulty comes from how the hyperdash is used in a pattern. Exponential distance scaling should handle hyperdashes adequately enough.

Reduce Speed Scaling

SR growth from high BPM values is simply too high. High BPM beatmaps can easily achieve SR values well above 8*, see https://osu.ppy.sh/s/432720 and https://osu.ppy.sh/b/1632808 . At more moderate BPM values stream jumps are problematic too.

Live
StrainTime = StrainTime
StrainTime cap = 25ms

New
WeightedStrainTime = StrainTime + 20
StrainTime cap = 40ms

By increasing the SrainTime cap to 40ms (equivalent to 375BPM streams) it stops the ridiculous growth seen at very low StrainTime values, usually from beatsnaps upwards of 1/8. At these values any significant movement is likely to create a hyperdash which will teleport the catcher without requiring the player to hold dash, also known as a hyperwalk. See https://osu.ppy.sh/b/944502 for an extreme example.

Add Antiflow Bonus

The existing direction change bonus results in flowing patterns being rated more than antiflow patterns.

Quick note on what is meant by flow and antiflow here. Flow is somewhat like when a pattern allows the player to carry some momentum into it. See how in the image below the direction changes are on the notes before and after the jump. Simply put, the movement has a flow to it.

Flow

Antiflow is basically the opposite. Direction changes are made on the notes in the jump and the particularly tricky bit is the direction change at the end of the jump as the player cannot carry any momentum into it. In the context of SR calculation, antiflow will be the strength of a movement before a direction change.

Antiflow

The new antiflow bonus weights a direction change based on the strength of the movement before it.

Live
direction_change_bonus = 12.5

New
direction_change_bonus = 9.5
antiflow_bonus = 25.0

double antiflowBonusFactor = Math.Min(Math.Abs(distanceMoved) / 70, 1);

distanceAddition += (antiflow_bonus / (catchCurrent.StrainTime / 40 + 10)) * (Math.Sqrt(Math.Abs(lastDistanceMoved)) / Math.Sqrt(lastStrainTime + 20)) * antiflowBonusFactor;

The old direction change bonus is only slightly reduced as part of larger balancing efforts. It’s important to still give a base bonus to direction changes as to not completely devalue flow movements.

The antiflow bonus is scaled by a separate bonus factor to the one used for the direction change bonus. This attempts to prevent patterns like this from being too highly rated. Without the bonus factor, this pattern would be the new bread and butter of pp mapping.

The bonus currently uses the square root of the last distance moved as opposed to linear scaling. Linear scaling seems to only really reward beatmaps with large cross screen jumps and leaves others rather underrated in comparison.

Reduce Distance Scaling

As part of balancing all these changes, distance scaling is also reduced a bit as large jumps are rated much higher with the antiflow bonus.

Live
distanceMoved^1.3 / 500

New
distanceMoved^1.3 / 600

Increase Base Bonus For Every Movement

There’s an existing base bonus for every movement which, as the comment in the code says, gives weight to streams. Increasing this helps give a bit of weight to smaller movements in beatmaps which aren’t rated highly due to their lack of distance.

Live = 7.5
New = 10.0

Remove SR inflation caused by wide buzz sliders

This fixes the issue outlined in #82

The implementation is pretty much as proposed but now scales between 80ms and 60ms.

Near enough fixes the issue without impacting innocent beatmaps. SR growth from these stacks can still happen but it is far less extreme.

if (Math.Abs(distanceMoved) > 0.1)
{
	if (Math.Abs(lastDistanceMoved) > 0.1 && Math.Sign(distanceMoved) != Math.Sign(lastDistanceMoved))
	{
		if (Math.Abs(distanceMoved) <= (CatcherArea.CATCHER_SIZE) && Math.Abs(lastDistanceMoved) == Math.Abs(distanceMoved))
		{
			if (catchCurrent.StrainTime <= 80 && lastStrainTime == catchCurrent.StrainTime)
			{
				distanceAddition *= Math.Max(((catchCurrent.StrainTime / 80) - 0.75) * 4, 0);
			}
		}
	}	
}

Adjust Star Scaling Factor

Final change is a slight adjustment to the star scaling factor. This is to keep overall numbers hitting similar ranges as before.

Live = 0.145
New = 0.15

Check out this spreadsheet to see an example of all these changes on a few beatmaps.

These changes certainly don’t “fix” catch SR, beatmaps are still over and underrated but most see improvements in the right direction. Converts and specifics seem much better matched and SR values at the high end look to be more sane, it’s much rarer to see a beatmap above 8 stars.

On the lower end things might look more familiar, Cups and Salads are at very similar SR values compared to live. Most Platters see a slight decrease and most Rains see a varying decrease due to flow and speed changes. Overall there doesn’t appear to be any adverse effects on lower difficulties.

@Xinnoh
Copy link

Xinnoh commented Mar 5, 2019

👍 everything here makes sense to me

@Fericiano-Fluorite
Copy link

Just my 2 cents

  1. I'm concerning how tap dashes are considered in this proposal. Standing-still -> strong-movement (in the same direction) patterns are also considered antiflow but they don't seem get addressed here.
  2. May add some additional SR/PP reward for special cases: low AR for HD, for example. The detail may refer to STD SR change recently.
  3. Aside from being reasonable of adding edgedash threshold distance, I'm thinking about some 3/4-slider edge dashes maps, which may get highly boosted on their SRs with this proposal. However in many cases 1/4 edge jumps are not as hard as ones with longer strain time (1/2, 1/1), so I think time gap of edge dashes should be added into consideration as well.

@cl8n
Copy link
Member

cl8n commented Mar 5, 2019

^ let's look for those cases when testing against the full set of maps/plays. otherwise LGTM

@Sorceress4628
Copy link
Author

Sorceress4628 commented Mar 5, 2019

@Fericiano-Fluorite Considering and balancing same direction movements is a much trickier problem to solve. It's definitely something worth looking in to but I didn't want to hold back this proposal for it.

Good point on the edge dashes, will look into that. Though as cl8n suggests, I'll wait for full testing before making any further adjustments or I'd end up making changes for all eternity. I am a liar, I still don't want to keep endlessly tweaking but the edge dash change is too good to pass up on.

As for things like low AR hidden its handled outside of SR. I'd like to get some proposed changes out soon alongside this to the performance points side of things.

EDIT 07/03/19: Updated the main post and spreadsheet values

  • Edge dash bonus is now reduced at low ms values.
  • Antiflow Bonus adjustments
    • catchCurrent.StrainTime scaling reduced, lastStrainTime scaling increased
    • antiflowBonusFactor now scales linearly

@ShinyNT
Copy link

ShinyNT commented Mar 12, 2019

I really liked all proposals made here, especially the Edge Dash and Antiflow ones, which have been for sure a problem in converted maps. Can't say so much about the others (I mainly play Cup<->Rain), but they seem to be in a right way.

@Lacrimaa
Copy link

I wonder how patterns like in the image are calculated, as well as all patterns which require rapid tapping on only right/left/dash button
12855595

@Sorceress4628
Copy link
Author

Same direction movements like that are not really accounted for on either live or this proposal. Though with the changes in the proposal, beatmaps with a lot of difficult same direction movements will probably be more noticeably underrated.

It's a much trickier problem to solve than something like antiflow. Even if you isolate the conditions, balancing all the factors involved is a big task. The speed and distance of notes in patterns like these is very important. At what distances and speed does the player no longer need to vary the catcher speed and can just hold dash? What about not needing to hold dash at all like in this beatmap.

It's absolutely worth looking in to but it's a lot of work, don't want to hold back this proposal for it

@Lacrimaa
Copy link

I'll leave this here
HR is definitely overweighted now, as well as antiflow movements
image

@Sorceress4628
Copy link
Author

No need to worry, just some bugs with lazer. Check out these maps with HR on lazer and you'll see why the PP values are so crazy. Spec's ONIGIRI FREEWAY also seems to have some issues and I'm fairly sure EZ is doing something funky aswell. Converts are also using live values which is why they're still rather absent in most players top ranks.

It will all be sorted soon enough, in the meantime if you want to try look through the rankings, pay no attention to any HR, EZ or convert scores

@cyathree
Copy link

As a convert player myself, please consider toning down the edge dash bonus down to 3.5 or something. While edge dashes can be a bit of a struggle at times, majority of them are pretty manageable to hit with a few windows being v punishable if the player reacts too late. I don't really agree with converts rewarded as 5*+ & having former ~5.5* specifics (ex. spec's piranha) getting toned down as ~4.8*. The skills are different yeah but like the old system, it feels a bit unfair for one skill being favored more than another.

Gonna link a few examples of some scores I've done if you want to compare data for a bit
https://sorcerer.smgi.me/beatmapsets/559489#fruits/1183255 - 4.73* 246.44pp -> 5.42*, ss 323pp
https://sorcerer.smgi.me/beatmapsets/823259#fruits/1725347 - 4.71* 210.46pp-> 5.33*, 2 miss 269pp
https://sorcerer.smgi.me/beatmapsets/310717#osu/694350 - 3.65* 149.95pp -> 5.02*, fc 252pp

thanks for reading

@Sorceress4628
Copy link
Author

Difficulty Calculation Changes

Edge Dash Bonus

An edge dash, also known as a timing jump or pixel jump, is when the distance between two notes is very close to triggering a hyperdash, requiring the player to use the edges of the catcher to be able to catch the fruits. The precise movement and timing required makes these dashes fairly tricky.

The existing edge dash bonus has been noticeably increased. Additonally, the bonus is scaled by strainTime, reducing the bonus at lower ms values where edge dashes are actually easier as the hyperdash generation threshold is more lenient.

Old
Bonus = 1.0
Edge dash threshold = 10

New
Bonus = 5.7
Edge dash threshold = 20
Edge dash speed scaling = Bonus * (Math.Min(catchCurrent.StrainTime, 265) / 265)^1.5

This gives a significant increase to SR on beatmaps with edge dashes, most notable on converted beatmaps.

Hyperdash Bonus Removal

There was previously a bonus for hyperdashes and edge dashes on a direction change. This bonus did extremely little for edge dashes yet had an unnecessarily large impact on hyperdash heavy beatmaps, most noticeable on Overdose level Specifics. Overall this bonus was not accurately reflective of difficulty and has been removed.

Reduce Speed Scaling

Star Rating growth from high BPM values has been reduced to bring speedier beatmaps down to more sane values.

Live
StrainTime cap = 25ms

New
WeightedStrainTime = StrainTime + 16
StrainTime cap = 40ms

Direction Change Bonus Adjustment

The direction change bonus has been adjusted to primarily consider the movement before the direction change. This should more accurately represent difficult direction changes.

Live
direction_change_bonus = 12.5

New
direction_change_bonus = 21.0

double antiflowFactor = Math.Max(Math.Min(70, Math.Abs(lastDistanceMoved)) / 70, 0.38);

distanceAddition += direction_change_bonus / Math.Sqrt(lastStrainTime + 16) * bonusFactor * antiflowFactor * Math.Max(1 - Math.Pow(weightedStrainTime / 1000, 3), 0);

The maximum on the antiflowFactor ensures all direction changes still have some value as opposed to only valuing those with large distances before them.

Reduce Distance Scaling

As part of balancing all these changes, distance scaling is also reduced a bit as large jumps are rated higher with the changes to the direction change bonus.

Live
distanceMoved^1.3 / 500

New
distanceMoved^1.3 / 510

Increase Base Movement Bonus

As most of these changes result in lower Star Rating values across the board, the base movement bonus has been increased to bring overall numbers back up.

Live = 7.5
New = 12.5

Adjust Star Scaling Factor

Much like with the base movement bonus, the star scaling factor has been increased to balance overall Star Rating values.

Live = 0.145
New = 0.153

SR inflation from wide buzz sliders #82

While no specific changes have been made to deal with this issue, the changes to the direction change bonus and strainTime weighting have dramatically reduced the SR inflation caused by wide buzz sliders.

Performance Points Changes

Reduce Length Bonus

The Length Bonus has been reduced to bring down the PP values seen on longer beatmaps.

Increase High Approach Rate Bonus

The bonus for Approach Rates higher than 10 has been increased by 10%, scaling from 10% at AR 10 to 30% at AR 11.

Fix Hidden Scaling on High Approach Rates

The Hidden bonus scales inversely with Approach Rate as Hidden becomes easier at higher AR. The bonus now correctly continues to scale down above AR 10 to 1% at AR 11 as opposed to bottoming out at 5%.

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

No branches or pull requests

7 participants