Increase SR for beatmaps with high bpm streams (220bpm+)

[Xexxar]

Hello!

I've been wanting to propose this for a while and I've been trying to come up with a good way to build up data but after several nights of trying to convince a friend to help me I decided to compile some small results and ask others (Reddit, w/e) to assist me.

It is widely accepted that high BPM streams are currently not accounted for / balanced properly in the current algorithm. But for those that need further explanation, let's break it down.

Currently, incredible scores such as bro_gamer72's Choir Jail DT score are rarely even worth 600 pp. (found here: https://osu.ppy.sh/beatmapsets/172688#osu/435350). As a one of a kind score, it's quite disappointing to see such a small amount of pp for something this impressive. We could also consider his DT choke on Dragonforce - Symphony of the Night rather low PP given how few players even come close to matching it. (found here: https://osu.ppy.sh/beatmapsets/469148#osu/1007546)

Beyond just individual scores however, it is clear that there is an advantage for aim players in the high ranks, as nearly all top players focus on aim. Player's like bro_gamer, ming, XII, etc, do not have fair representation in the top 50. What I hope to do with this change is promote more variance in what skills are shown off in the top 50.

With that out off the way, what I am proposing is a buff to all streams that exceed 220 bpm. What I am doing in my edit to the code is checking the MS between the previous note and the one we're currently looking at. If it is below 68 (220 BPM 1/4th), then we start scaling it linearly via the following formula.

speedBonus = 68 / current.DeltaTime;

Which provides a bonus of 1.09x for 240 BPM, 1.18x for 260 BPM, 1.36x for 300 BPM, etc.

Here is an example of this code in action with some values for SS's on several maps:

http://puu.sh/Anrjw/209100e5df.png

One of the best parts of this change from my perspective is how maps like Sakura no Uta DT, which feature 270 BPM streams, actually receive a benefit from this change, whereas maps like Anime-Ban, or Sotarks' Song Compilation receive no change, since those maps do not have streams.

I am willing to collect more data, but my coding knowledge is very limited so doing it by hand is very tedious and not effective at all. If there are people who have the necessary skills and would like to assist, please do so using this PR thread so we can build better statistics and understand how this change will effect much more of the game. The only way this change can be implemented is if we have proper data to show the effects of this change, so lets get to it!

Thank you for reading

[CaptainTristana]

This should definitely scale with the amounts of actual streams in the map. Few bursts here and there? no much change, huge deathstreams? Well deserved buff

[efci]

support

[grumd]

A slightly more mathematical approach to analyzing this problem:

Currently the formula for speed strain is speedValue / current.DeltaTime. Speed value is basically a constant (depends on spacing), and delta time is the variable that's dependant on BPM.

So if I want to plot how the speed strain depends on BPM, I'd use a formula like 1 / deltaTime where delta time is a variable. The formula to convert BPM to delta time (for 1/4 spapping) is DeltaTime = 15000 / BPM.

So, for 1/4 streams, speed strain depends on bpm like speed strain ~ BPM / 15000, which means it's a linear function. It basically looks like this:

So, the idea here is to increase the speed strain for higher BPM. Your solution basically does this:

Which is a combination of these two functions:

It increases reward for anything above 220 bpm. In my opinion, it's pretty arbitrary and isn't the best solution. I'd probably use a single function like the third one here:

It will increse more with higher BPM until it reaches infinity at something like 500 bpm 1/4 streams.

This function would most likely require to make speed reward for lower bpm clicks smaller, e.g. single taps at 180 bpm would give less pp in speed department (still the same pp in aim though). I don't know how to recalculate scores with a new formula to see the real world difference though.

When comparing this to Aim calculation, aim calc is linear, just like speed calc is now. I'm not sure, maybe aim should also be non-linearly dependent on delta time?

[CaptainTristana]

grumd's solution is better only if there is a way to NOT nerf lower BPM
basically make the before certain BPM more linear to mimic it's current value as they does not need any sort of nerfs imo

edit: grammar

[kk1995]

@grumd It seems we separate streams vs single taps via spacing as seen in osu.Game.Rulesets.Osu/Difficulty/Skills/Speed.cs line 24 - 34.

I also don't like the arbitrary 220 BPM threshold. Just to make sure I have the correct understanding, is the plot below the expected speed value (relative) for both old and new algorithm? Blue is current while red is Xexxar's input. For current algorithm I made speed bonus 1.

[kk1995]

@grumd The assumption that 500 bpm is unreachable is probably true, but I still liked Xexxar's method since it provides a nice quadratic relationship in which the speed bonus value doubles every 220 BPM.

The 220 BPM is still up for debate, but I tried to find a continuous function that fits Xexxar's idea pretty well. Let me know what you think.

Algorithm:

double bpm = 15000 / current.DeltaTime;
speedBonus = 3.4 *Math.Pow (5e-4 * bpm * Math.Sinh(1 / (5e-4 * bpm) ) - 1 ) , -1/2) + 0.9;

The results are as follows:

There is a small increase in bonus before 220 BPM with this method. However, the bonus value only increases by 8.69 % from 150 BPM to 200 BPM, which I think is sensible. There is an increase of 2.44% from 200 BPM to 210 BPM, and another 2.66% increase from 210 BPM to 220 BPM.

Bonus is 1 around 199 BPM.

P.S. I was doing this on MATLAB so I don't know if you copy and paste that code it works on C#. Might need to debug a parentheses or two.

[Xexxar]

Can I ask why we're trying so hard for a non-linear relationship considering we're only looking at one object here? I don't see why we have to scale in a non linear fashion when we're only buffing one object of many that will be beyond a certain threshold of comfort. These graphs may look cleaner, but there is no reason to put that much computation into what will ultimately be extremely minor differences in SR and PP. Graph the the resulting maximum value of speed strain from 16 objects using the two different algorithms with the X value being BPM, one that is linear and one of these fancier ones. Those graph will look curved in a natural way that difficulty should, regardless of which one you use.

In regards to grumd's graph where 500 BPM has such a huge buff, a mapper might put a 1/8th triplet in his 250 BPM map and now there is a huge buff (infinite apparently) for something that isn't even that hard. A linear relationship is fine.

I chose 220 BPM as the cut off point because it is commonly considered to the upper limit of what is in the comfortable farmable range, that is between 180 and 220 BPM. If you make this relationship non-linear then you will buff ranges you may not necessarily want, such as maps like Road of Resistance etc.

[hikizisa]

I think main problem with those maps are spacing of the stream rather than bpm.
even for lower bpm, a lot of well known stream maps give much pp only with HR, which make those maps have enough spacing. Most of speed plays are on stream maps without much spacing too
thus giving more speed value to less spaced streams would fix both problem in better way

[Mini-Gaunt]

I think that using a non-linear algorithm will help make sure a "deathstream meta" doesn't start abusing bpm plateaus. What I invision is only maps that get the most optimal benefit become popular.

Other than that small issue, which would be a welcome change from the jump meta, I don't see why this change shouldn't go through.

Also I might be a little ignorant about the exact pp calculation, but I imagine most people's idea of a high bpm stream balance would be to make acc more punishing as the speed value increases. How effective would that be in balancing speed value around double tapping?

[Xexxar]

Given that the bonus to speedValue is a continuous function in the way it is written here there literally is no value that can be "abused" in the way you say. As for double tapping it can just be patched out if it becomes an issue. I want to rework the way accuracy works at a later time anyway.

Deathstreams are currently not balanced within this rewrite since plateaus of speedStrain will still exist, it just means that these plateaus are higher at higher BPM. If we want to eventually create benefits for streams that are over 128 notes etc, a more in-depth algorithm will be required to assess this.

[kk1995]

@Xexxar I don't think your proposed algorithm is bad at all. I am not familiar with mapping so correct me if I am wrong, but there is an additional pp benefit applied when AR is greater than 10.3 and how that benefit works is similar to your proposal. As a mapper, do you think mappers abuse this by making farming maps' AR higher than 10.3 (legit question I am not good enough to play those maps)? I am actually not sure if that sharp change in speed bonus would be "abusable", but I wanted to remove that possibility entirely by providing a continuous alternative. As I said before, I think yours will work just fine and mine is an addition that could be considered.

About computation speed, yes continuous alternative will be more costly. However, whether that matters is based on how often this is calculated. I do not know that so I will not say anymore on this.

Finally thanks for getting this thread started. It is probably a change that a lot of people have been thinking of, yet you were the one who was proactive enough to start this discussion and put in the effort.

[llyyr]

Deathstreams are currently not balanced within this rewrite since plateaus of speedStrain will still exist, it just means that these plateaus are higher at higher BPM. If we want to eventually create benefits for streams that are over 128 notes etc, a more in-depth algorithm will be required to assess this.

I don't think this should be merged until a more in-depth algorithm is made to take the length of streams (along with aim values) into account. This creates a bonus above an arbitrary selected BPM without taking the actual stream difficulty into account.

grumd's solution is better if you make sure mappers can't abuse it by using "1/8th triplet in his 250 BPM map", which can be done taking the length of streams into account.

[kk1995]

@llyyr Length of stream is somewhat taken into account because difficulty is calculated for a section and long streams would yield higher summed speed value. Fixing this would require the sectioning process in difficulty calculation to be revamped, which would be quite complicated. I agree it should be changed eventually.

However, for the sake of keeping the progress going we should implement @Xexxar 's idea since it seems to be in the right direction. Implementing this doesn't mean more changes won't be made. For stuff about continuous function I introduced an algorithm but that doesn't mean I think it is critical. Xexxar's algorithm should be in the right direction roughly.

TLDR: Let's implement @Xexxar 's proposal since it is in the right direction and if there is something wrong we can fix it.

[llyyr]

You can't be changing the pp system every day you wish to, Xexxar has already said he has multiple other ideas he'd like to merge which is great. They should all be merged at once rather than like this. As a player it's extremely demotivating to see your rank going up and down every week even though you did nothing.

However, for the sake of keeping the progress going we should implement

"For the sake of making it look like we're improving things, let's do a lazy change with arbitrary selected values even though we know it will cause problems in the future", but hey we can change it again in the future so it's fine, right?

This is the wrong approach to this in my opinion. Like for example, you're judging this change in a vacuum. You have no idea what affect the future changes Xexxar proposes will have on the pp system.

Ultimately, you're improving the pp system for more player enjoyment. And the players won't like to see their pp and rank changing every morning they wake up.

[Feuerholz]

Agree with llyyr that this should be applied only when everything related to it actually works, if you want to both buff stream bpm and properly reflect stream length do both at the same time, rank fluctuations are annoying when they happen too often. I think we can all agree that high bpm streams do need buffs, but if you have plans to do it properly, it's better to do that instead of applying some very arbitrary bandaid fix that I can definitely see being abused through low spaced medium length streams in higher bpm maps (as lower spacing is significantly easier to mash through).

Having part of the bonus be to accuracy instead might not be a bad idea actually, low OD streams have a lot of leniency anyway and FCing them becomes significantly easier than higher OD, not just accuracy (notelock is only an issue if you miss, so it's irrelevant here).

And be careful with overbuffing things purely based on uniqueness, if only very few people have a skill, especially one that isn't "meta", it is pretty much always partially caused by most others not trying particularly hard to develop that skill in the first place.

Also regarding doubletapping - as far as I'm aware it can't just be patched out, I recall a tweet from millhi when he patched it in that it always worked on his laptop, but not after he used a regular keyboard, which would indicate that patching it out would just lead to device inequality.

[Karthyz]

While I like this change, I do agree that it would probably be worth while to take stream length into consideration before making it final, I feel like maps with short bursts every now and then are getting buffed a little too much in this while maps with stamina intensive long streams are mostly ignored because they're not "fast". Stamina and speed are so closely linked I think it's worth balancing both together.

[Xexxar]

I think people completely misunderstood the real intentions of this change. I'm not here to buff stream length / stamina (I have tested a lot of options regarding this, there are basically no balanced ways to do this without a new skill introduction). The goal of this change is to stop maps like this from being overweighted / ranked:

https://osu.ppy.sh/beatmapsets/745312/#osu/1571309
https://osu.ppy.sh/beatmapsets/623924/#osu/1474956
https://osu.ppy.sh/beatmapsets/736560/#osu/1554502

(Seriously, look at the top and bottom links and look at how Sotarks chooses his 6* rhythms. You'll notice that he literally puts 1/4th sliders every chance he can instead of actually putting a triplet or a stream. He's the PP shitlord, it should be a a sign that something is seriously wrong.)

Specifically with both of the maps by Sotarks, it has gotten to the point where deliberately avoiding mapping active 1/4th rhythm (even when its supported by the music) is more advantageous PP wise than properly mapping the song. The reason why you all should be perfectly okay with maps like Sunglow, Akatsuki Zukuyo, etc. getting buffs is because of the fact that this mapping by Sotarks is an EXTREME problem. It should be abundantly clear that allowing the system to benefit mappers / players who deliberately avoid mapping elements that require the player to engage in streaming or speed focused play is extremely toxic to the ranked map pool.

It is not like these maps are getting massive buffs either, and it should also be mentioned that "speed" has always been a hybrid of both streaming and general tapping stamina. Maps like Akatsuki Zukuyo that actually require the player to have both extreme high aim and speed skills are what will be the maps that reward the highest PP values, rather than maps like Sotarks' PP Compilation, a map that is an insult to any mapper who actually tries to follow the song properly. The buff to Time Freeze is also substantial, albeit not enough to properly reflect the difficulty of the song (see squares, kick slider jumps, linear flow jumps, general extreme stamina, etc.)

The new PP maps that will result from this change will actually properly contain all gameplay elements (atleast all of the ones that are worth PP under the current algorithm), instead of maps that have jumps and only jumps. Yes, plays that are extreme stamina intensive are impressive, and fancy have it that those maps will also receive buffs as evidenced by bro_gamer72's scores that are gaining upwards of 100 PP. The issue with trying to assess stamina is that the speed algorithm never was supposed to assess stamina and only stamina. This is the reason why it scales with distance, it is a measure of stream aim, jump stamina, etc. just as much as it is a measure of 1/4th death streams. You cannot fix stamina without introducing a new skill and working HEAVILY on balancing it.

If you have a proposal that can do that, please post it. But until then, this change is not for that.

And just a bit more evidence for my argument:

Currently, Sunglow (a map with streams and actual triplets, 5 note streams) is worth 210.87 speed PP for an HDDT SS. However, Sotarks' Song (PP) Compilation (where triplets are 1/4th repeat sliders, there is no stream longer than 5 notes and they always end on a slider because clicking a jump after a stream is hard) is worth 216.21 speed PP. Akatsuki Zukuyo (a map with multiple streams exceeding 16 notes at 270 bpm), is worth 247.06 speed PP.

After my change, these become, 243.00, 216.57, and 307.41 speed respectively.

Do you guys understand now?

(sorry for being a little repetitive, I just want to make sure my point is absolutely clear)

[llyyr]

Well you never mentioned the "real intentions" of this change in the first post. In fact, you said exactly that "what I am proposing is a buff to all streams that exceed 220 bpm".

I don't have any problems with the end result that this change brings, it's better than before. But that's all it is. What I do have problems with is the process it achieves those results with and the lazy "Oh there's that problem with this change, but we can change that next week it's fine" approach it brings.

This just makes current Sotarks-type mapping give less pp, while opening up new exploits for people who exclusively map for low effort high pp to take advantage of. Something like this gains roughly 25pp with HDDT from this change. You're an active mapper, I'm sure you can make comfort maps with triples and 4-5 note streams in the 240-260 BPM range for players to farm.

I do not wish to come across as someone overly negative about this, but this change is a big ball of mud. It's an extremely high maintenance change, something that'll require a ton of work to get right, certainly not just introducing two new integers. You admit that there is a lot of room for improvement with this change, actually buffing long stamina intensive streams instead of adding a bonus to everything for example, which this change ignores.

[Xexxar]

I do not believe you can balance an algorithm properly unless you make changes one at a time. You may disagree with my methodology and that's perfectly fine, but my goal is to make steady improvements overtime that will bring us closer to where we want to be. If you have better ideas please be my guest and implement them on your own.

My change does in fact buff all streams that are greater than 220 bpm. You all just see the fact that some DT maps with streams (11-16 notes) that are greater bpm than 220 and say "those aren't streams" even though they are. I am an active mapper and I can tell you that with this change triplets and 4-5 note streams will not become pp farm, it just wont Test it and find a way to abuse it if you believe you can. The longer the stream the bigger the buff this will have fundamentally, since the bonus stacks on top of itself for each note.

Thats why Sunglow gains only 30 PP.
Thats why Akatsuki Zukuyo gains 60 PP.
Thats why Choir Jail gains over 100 PP.

If you're saying you want me to continue making more PR's that can fix other issues such as stamina, high velocity sliders, jumpstreams, high bpm alt maps, ultra high bpm jumps, accuracy, and many other issues, sure I plan to over time, as long as I've tested and made sure that each and every small decision I do has a net positive change on how it will impact the algorithms integrity overall. I am not going to try to fix everything at once because that is NOT reasonable and NOT doable. No system is ever going to be perfect. If you want it to be, make it yourself.

This is why the idea that "ppv2 is fundamentally broken, we need to fix it from the ground up" is completely uncalled for. I will stick making small contributions that improve the quality of the game over time instead.

[Master-chan]

I think people are trying to come up with non-linear formulae just because nobody really understand where did 220BPM come from, and why should it be a break point for buffing.

[Karsten-Allison]

https://osu.ppy.sh/s/364938 on the topic to the partial reason why xexxar doesn't want exponential scaling, if you take the map I just linked and look at 00:03:092 (1,1,1,1,1) - you'll notice a 5 note burst that is higher then 300bpm nomod, on a map that has a few dt scores already. If the bpm curve is too exponential it could make a map like this gain a unworthy amount of extra speed pp for having a random high bpm burst.

[kiranation]

isn't it better to just multiply pp by BPM?

[Xexxar]

220 BPM is an arbitrary value assigned under a logical assumption that streams beyond that point become more difficult at a higher rate than streams transitioning from say 180 BPM to 220 BPM. Beyond this, it is easier to make sure that maps that do not need buffs do not get one. The value happened to work well and gave bonuses in the realm that I felt was appropriate for the difficulty. If someone wants to implement a different change to the algorithm that does produce a non linear dynamic, they're more than welcome to, I simply felt it was unnecessary. I also would like to remind everyone that as long as the equation preserves continuity there is no risk of any one BPM becoming "overweighted" per say.

Exponential algorithms run risks as defined by some of the other comments on this board. As for the comment on "multiply pp by BPM," this is immediately invalid since there are maps that utilize 1/6th, 1/8th and other snap values for streams, so that is entirely arbitrary.

I hope to eventually try and implement an additional difficulty class called stamina.cs that will hopefully fix some of the issues of underweighted death streams as a result of the issue of plateauing that occurs within the speed.cs class. However, I'm once again going to appeal to everyone's sense of reason. If you believe my implementation here is not satisfactory I implore you to attempt your own and file a separate pull request that may address this issue better than mine does, perhaps simply linking it to this thread afterwards.

[Magnus-Cosmos]

Instead of multiplying everything by the speedBonus, we can adjust the bonus depending on the spacing, this would solve the issue of stacks (e.g. triples) being buffed (which also means that this somewhat defers double-tapping, since double-tapping a spaced 300bpm stream would be much harder than a standing 300bpm stream).

            if (current.DeltaTime < 68) // 68 = 220 BPM 1/4th snapping in MS.
            {
                speedBonus = 68 / current.DeltaTime - 1.0;
            }
            else
                speedBonus = 0;

            double speedValue;
            if (distance > spaced_spacing_threshold)
            {
                speedValue = 2.4 + (distance - spaced_spacing_threshold) / 90;
                speedValue *= (1.0 + 1.5 * speedBonus);
            }
            else if (distance > single_spacing_threshold)
            {
                speedValue = 2.1 + 0.3 * (distance - single_spacing_threshold) / (spaced_spacing_threshold - single_spacing_threshold);
                speedValue *= (1.0 + 1.2 * speedBonus);
            }
            else if (distance > stream_spacing_threshold)
            {
                speedValue = 1.6 + 0.5 * (distance - stream_spacing_threshold) / (single_spacing_threshold - stream_spacing_threshold);
                speedValue *= (1.0 + speedBonus);
            }
            else if (distance > almost_diameter)
            {
                speedValue = 1.2 + 0.4 * (distance - almost_diameter) / (stream_spacing_threshold - almost_diameter);
                speedValue *= (1.0 + 0.8 * speedBonus);
            }
            else if (distance > almost_diameter / 2)
            {
                speedValue = 0.95 + 0.25 * (distance - almost_diameter / 2) / (almost_diameter / 2);
                speedValue *= (1.0 + 0.5 * speedBonus);
            }
            else
                speedValue = 0.95;

[MillhioreF]

Bumping this PR. After significant discussion in #osu-performance on discord, the reception to this change has been received very warmly, and people would rather see this before the short map nerf.

If there's a blocking problem with propagating SR changes (as has been alluded to by the PR owner) that should be high priority to address, since all significant changes to pp require changing the SR and we can't really make forward progress otherwise.

[smoogipoo]

Note: Due to the possibility of a div-by-0 (or close to it), I've used StrainTime instead, which caps at 300bpm 1/4. Though I think this is a pretty sane cap since 300bpm 1/4 is basically unplayable anyway.

[smoogipoo]

Did some preliminary pp-recalc on the top 10000 users provided in the current dumps:

https://docs.google.com/spreadsheets/d/1faqOsqVPyaZp5ls9_45PLvCR6h1CnCu_qRXtdmsI918/edit?usp=sharing

[Xexxar]

Is there any motivation to replace the linear piece wise function with a non-linear function? I know many people have brought it up before, so I figured we should discuss this before implementation. In addition, there are ranked maps that do exceed 300 bpm 1/4th, so it might be worthwhile to make the maximum bonus value in the 350~ bpm range. Besides that, 220 BPM is an arbitrarily chosen starting value. Would people oppose lowering the buff range to start at 215 bpm. This way maps that are 220 bpm (which don't seem to be commonly farmed) would get a small buff whereas they get nothing with the current implementation.

[VINXIS]

When we are starting tests for this I'd definitely consider trying out 210 (or even 200) as the start of the speedBonus instead of 220 because as it currently stands, speed stuff is currently SUPER underweighted and I'm not sure if 220 would be low enough, especially considering the highest speed players usually go is like 300, and the fact that hard fast stream maps like eiji kuinbii would still get barely a buff when its definitely worth more than even 400 pp

Just realized xexxar asked this in the previous comment woops but yea, to his question i would agree lowering the buff range's min

[girantinas]

@VINXIS Piecewise function from 200 bpm to 220 bpm as one branch and then 220bpm and beyond as another branch may be a possibility. However, the amount of pp you get for should not scale linearly with bpm. Going from 220 to 240 is much easier than 240 to 260, so it should not have the same pp difference. So either you have a line from 200 to 220 and a curve from 220 and beyond or a curve the entire time. I decided on a cubic curve the entire time. Here is a graph that you can change the parameters of an see how it reacts. https://www.desmos.com/calculator/zahq8zudly
This could also made a line from 200 to 220, put a point of inflection with the same slope as the line at 220, then continue with a cubic curve.

[Xexxar]

Under the current changes that have occurred to speedbuff following the angle changes, I believe the following speed buff should be implemented instead.

public class Speed : Skill
    {
        minSpeedBonus = 75 // 200 BPM
        maxSpeedBonus = 45 // 330 BPM approximately
        balance = 40; // variable for making sure values behave nicely
        deltaTime = current.DeltaTime;
        speedBonus = 1.0;

        if (deltaTime < maxStreamBonus)
             deltaTime = maxStreamBonus;

        if (deltaTime < minStreamBonus)
             speedBonus = 1 + math.Pow((minSpeedBonus - deltaTime) / balance), 2);

        return speedBonus * (.95 + (Math.Pow(distance / SINGLE_SPACING_THRESHOLD, 4) * angleBonus)) / current.StrainTime;
// please note that I returned the 1.0 base value to its original of .95 
// also note that I believe this angle implementation to be correct, but smoogi's current version should be used to ensure things are correct.

By using speedBonus = math.Pow((minSpeedBonus - deltaTime) / balance), 2) we can avoid having an arbitrary starting value (at least a non differential starting value) and thus this means that the bonus can grow more naturally. Currently with this implementation here are some example values

bpm = 200 | 1.00x
bpm = 220 | 1.03x
bpm = 240 | 1.11x
bpm = 260 | 1.20x
bpm = 280 | 1.30x
bpm = 300 | 1.39x
bpm = 330 | 1.56x

I believe these values to be relatively reasonable, but if there is any dissent please speak up. Thank you as always, and I look forward to seeing new rankings soon.

[smoogipoo]

Original:
https://original.smgi.me

This PR:
https://xexxar-sb.smgi.me

[smoogipoo]

Closing as this has already been done in a different way (see "High BPM streams" section of https://osu.ppy.sh/home/news/2019-02-05-new-changes-to-star-rating-performance-points).