A potential fix for AR

[Magnus-Cosmos]

Reworking from scratch, focusing on high AR first, then low AR (since low AR is more complex in my opinion, because many things attribute to reading, while high AR is mainly dependent on reaction).

[Magnus-Cosmos]

I don't believe a length adjustment is needed, and it might unintentionally nerf maps (such as easy/normal diffs), but I'm putting it here just in case anyone can create any good ideas from this.

Possible adjustment for length (though I feel like it isn't that necessary), this is just some rough estimate, since I don't expect a length adjustment to go through, values could probably be adjust much better:

	// Add under if approachRate<9.0f and if approachRate>10.33f
	if static_cast<f32>(numTotalHits) > 2000.0f
		approachRateFactor *= (1+static_cast<f32>(numTotalHits)/2000.0f)*0.02
	else if static_cast<f32>(numTotalHits) < 500.0f
		approachRateFactor *= (1+static_cast<f32>(numTotalHits)/500.0f)/1.05

[LeaPhant]

Hey, from the code it's not visible at which step of calculation you're grabbing _speedValue, could you give more information at which point that bit is gonna be inserted?

Edit: Same for _accValue.

[Magnus-Cosmos]

Oh, the spot would be same as where the current approachRateFactor is placed in the aimvalue calculation. https://github.com/ppy/osu-performance/blob/master/Src/Processor/Standard/StandardScore.cpp Basically, right before the finally multiplier added by HD/FL (since that's what I calculated the scores in my chart from).

[LeaPhant]

Okay, I can match all values except d.m.c [Insane] +HDHRDT. On this one I get a speed AR bonus of 1.71 which results in an oddly high speed pp value of 545 and therefore 1038 total pp (might be off since I'm using oppai to calculate star rating). Is it possible that there's something off with this map in the testing chart or is it on my end?

Edit: Tower of Heaven is 1412pp with 1.86 AR bonus. Could you maybe edit your fork to include the changes?

[Magnus-Cosmos]

I'm away from my computer right now and can't check, but I don't think the problem would come from my end since I used excel and applied the same formula to all the values, so if one is wrong then all of them should be. If you're using oppai, you have to remember to divide by the original AR and HD multipliers (since oppai gives you the final values, not the raw values).

[Nyanaro]

Basing something as complex as reading on something as simple as note density is very dangerous. Your current tests are too small of a sample size and don't cover all types of maps as the amounts of maps that would become overweighted would be outright silly, as note density is only one of many contributing factors to reading, making an algorithm like this incredibly easy to be abused.

Try theorizing and testing what reading actually entails, and what makes a map harder to read instead of going off something somewhat arbitrary as note density.

[LeaPhant]

d.m.c [Insane] +HRDT has a speed star rating of 4.02582 and 419 total hits according to the osu! data dump.

var _speedValue = Math.pow(5.0 * Math.max(1.0, 4.02582 / 0.0675) - 4.0, 3.0) / 100000.0;
_speedValue *= 0.95 + 0.4 * Math.min(1.0, 419 / 2000.0) +
	       (419 > 2000 ? Math.log10(419 / 2000.0) * 0.5 : 0.0);
// skipping combo since we're calculating FC
// speed is now at 263.272
// now the AR bonus would come into play according to your description
var approachRateFactor = 1.0;
approachRateFactor += 0.4 * (11 - 10.33) * (_speedValue / 100.0); 
// -> this results in 1.71, so speed pp is already over 450, I won't have to continue here

So either the position or the algorithm in your opening post is wrong. I guess I'm waiting for the fork edit as I'm really keen on trying this out on some maps, Pianom - Insaengui Huejeonmongma(ppongjjak ver.) [Happil] +HRDT for example.

[Magnus-Cosmos]

I'm not exactly sure how calculating _speedValue works from dump values, so I'll take a closer look at this when I come home. Looking at my chart, I probably made some stupid mistake in inputting the formula, guess I'll have to rework a bunch of stuff.

[Magnus-Cosmos]

My 2nd revision for the AR Fix/Rebalance:

Chart: https://i.imgur.com/558OtL4.jpg or https://ibb.co/mU1xrJ (for mobile) Important Reminder: This rebalance has little effect on most scores (mostly because it only affects the AR 9-10.33], it only has a significant effect on extreme cases. It took me a long time to adjust this in order to make sure some scores were not too severely nerfed/buffed.

Think of this as a small change/rebalance to the pp system (similar magnitude as the HD rebalance), although I do support larger changes such as adding aim flow, I believe that smaller changes like this are easier to accept and for people to get used to.

Thanks to @Nodebuck for actually checking my equations to see if they acted correctly (there was a large error in the first ver of the AR fix for high AR).

I went through a bunch of people's suggestions/comments, and it seems that my assumption on low AR was a bit wrong, as I prioritized Speed>Aim, thus in this revision, the low AR multiplier for Speed<Aim, however the curve for Speed is a bit higher (since I still believe that at very very high speeds, which usually means huge space streams or bpm abuse [which can be ignored], low AR does become more difficult, although the contradiction here is that Aim [flow] is also affected by speed). But overall, through all the beatmaps I've checked so far, this rebalance works well.

// Aim (Nerf for High AR and a highly curved Buff for Low AR)
	f32 approachRate = beatmap.DifficultyAttribute(_mods, Beatmap::AR);
	f32 approachRateFactor = 1.0f;
	if (approachRate > 10.33f)
		approachRateFactor += 0.25f * (approachRate - 10.33f) * pow(1.0f + _aimValue / 150.0f, 0.12f);
	else if (approachRate < 9.0f)
	{
		// HD is worth more with lower AR! Aim curves much faster with lower AR
		// (this was to ensure that low star rating maps were not buffed beyond reason;
		// most low star rating maps I checked are not significantly affect with this equation).
		if ((_mods & EMods::Hidden) > 0)
			approachRateFactor += 0.01f * (9.0f - approachRate) * pow(1.0f + _aimValue / 100.0f, 1.7f);
		else
			approachRateFactor += 0.005f * (9.0f - approachRate) * pow(1.0f + _aimValue / 100.0f, 1.7f);
	}

// Speed (Buff for both High and Low AR)
	f32 approachRate = beatmap.DifficultyAttribute(_mods, Beatmap::AR);
	f32 approachRateFactor = 1.0f;
	if (approachRate > 10.33f)
		approachRateFactor += 0.27f * (approachRate - 10.33f) * pow(1.0f + _speedValue/180.0f, 0.14f);
	else if (approachRate < 9.0f)
	{
		// HD is worth more with lower ar!
		if ((_mods & EMods::Hidden) > 0)
			approachRateFactor += 0.0055f * (9.0f - approachRate) * pow(1.0f + _aimValue / 100.0f, 1.9f);
		else
			approachRateFactor += 0.0025f * (9.0f - approachRate) * pow(1.0f + _aimValue / 100.0f, 1.9f);
	}

// Accuracy (Small Buff for both High and Low AR)
	f32 approachRate = beatmap.DifficultyAttribute(_mods, Beatmap::AR);
	f32 approachRateFactor = 1.0f;
	if (approachRate > 10.33f)
		approachRateFactor += 0.01f * (approachRate - 10.33f) * pow(1.0f + _accValue/100.0f, 0.01f);
	else if (approachRate < 9.0f)
	{
		// HD is worth more with lower ar!
		//Again, much larger curve for low AR in order to maintain pp for low star rating maps
		if ((_mods & EMods::Hidden) > 0)
			approachRateFactor += 0.001f * (9.0f - approachRate) * pow(1.0f + _accValue/200.0f, 0.5f);
		else
			approachRateFactor += 0.0005f * (9.0f - approachRate) * pow(1.0f + _accValue/200.0f, 0.5f);
	}

[Tom94]

Thank you very much for this PR! While the stated goal of this PR is to rebalance high-AR pp among speed and aim I can't help but notice that overall pp of DT plays (and DT+HR in particular) is going up quite a bit with this change.

I am not sure whether a buff for HD+HR+DT plays is truly necessary, given that those scores already provide quite a lot of pp. I, personally, would prefer to rather see a bias against DT and promoting HR a bit more, or at the very least, keep average pp roughly the same.

I'd be curious about the opinions of others.