Kert / osuSkills

osuSkills calculator
16 stars 5 forks source link

Multiple issues/proposals about memory points calculation #1

Open MBmasher opened 5 years ago

MBmasher commented 5 years ago
  1. Linear Flow Buff The current problem is that notes in a linear flow will give literally 0 points if the distance is smaller than the flashlight radius. This is a really bad idea because higher distance and less time between notes in a linear flow fashion requires good reaction to hit. What I have proposed, instead, is a nerf to circles visible within the flashlight circle. Instead of some circles giving 0 points, all circles will give the normal amount of points. However, if a circle is within the flashlight radius of another circle, this nerf will be applied. It is based on the distance between the notes. Higher distance means less of a nerf, so if the distance is like one pixel less than the flashlight radius then the nerf will be very small. If hidden is enabled, it will take into account the opacity of the note as well. The math:
    
    0 <= opacity <= 1

observable_nerf = (distance / flashlight_circle_radius) ^ (opacity)


2. Hidden Buff
After applying the linear flow buff, hidden gave less of an impact on the points that a map gave. In the current system, hidden only gives a big buff because there are no approach circles, meaning that less circles were observable and thus less circles would give 0 points. The problem is that distance is not a direct factor, meaning that if a note is not observable, no matter the distance, it would get the same buff from hidden. High distance with hidden is slightly harder than high distance without, and it should be rewarded more.
All I did was simple, if hidden was enabled, then the distance that is used for calculations should be raised to the power of a constant number. For my tests, I have used the number 1.15 (can be changed if desired).
3. Hidden Approach Rate Buff
The problem here is the same as the hidden buff. High distance is harder with low AR than high AR, but AR is not a factor in the current system either. However, I can't just blindly buff everything if the AR is low. If the time period between notes is long, then low AR is not necessarily hard. Therefore, I have made a buff which is based on both AR and the time period between notes.
The math:

max_AR_buff = 0.2 (can be changed if desired).

if time_period < ar_ms: hidden_AR_buff = 1 + max_AR_buff * (time_period / ar_ms)


4. CS Rebalance
At first, having CS as a factor in a flashlight point system doesn't sound like a good idea, since it is an aim factor. But, it makes sense if you think about it. If you've ever played a map with flashlight, low CS is not only easier just because it's easier to aim, but the precision at which you need to memorise is also less. Having maps which got nerfed when enabling HR was also a big problem. So, I propose this rebalance. It simply nerfs low CS and buffs high CS.
The math:

medium_CS = 36.49 (CS4, can be changed if desired). CS_rebalance_factor = 0.005 (can be changed if desired).

CS_rebalance = (CS_radius - medium_CS) ^ 2 if CS_radius > medium_CS: CS_rebalance = -1 CS_rebalance = CS_rebalance_factor CS_rebalance += 1


Here is a link to a spreadsheet with some example values: https://docs.google.com/spreadsheets/d/1_KY1XkYgdLx00Ga9q0hdJ4TnpqwQRdk6gNpZjTsHrOE/edit#gid=0

If you have any clarifications, please do not hesitate to tell me and I will clear it up if I can! Also, if you want to see maps then I can add them for you, ask for that as well :smiley:
Kert commented 5 years ago

Thanks for your contribution! Do you have some code ready so we can test this?

Kert commented 5 years ago

Thanks for the code. I've made some tests, got some mixed results. Tests were made using http://osuskills.com/user/Kert/skill/memory

Streamy maps got buffed too much: marisa map +HDHRFL 456 -> 663 tori no uta +HDHRFL 465 -> 621 thunder tornado +HDHRFL 300 -> 542

While some harder (imo) maps got even less points after the change: No, thank you +HDHRFL 652 -> 602 (faster + more jumps) Utsukushiki Mono +FL 574 -> 433 (just larger jumps) Gleaming Sky +FL 456 -> 416 (sheer length of it and sometimes objects are too far so you must memorize)

Most likely this happened because of the removal of zero-points-for-observable-objects condition. Though I do agree this probably needs to be toned down a little

Still I am pretty excited we're getting some traction!

MBmasher commented 5 years ago

okay two problems which is probably what's up with the first few maps

  1. CS rebalance probably needs more work, i think high CS is buffed too much (Edit: after thinking about it a bit, it's actually not THAT bad, we could just do something like lower the CS rebalance factor a tiny bit but the whole concept seems fine tbh)
  2. the hidden AR buff doesn't take distance into account, which explains those small spacing streams with HD getting buffed so much (especially since marisa +HRFL is only around 430) (edit: this is actually a very small issue since marisa +HDHRFL only changes from 663 to 647 when removing HD AR change)

After that last edit, it leads me to think that the reason for the high value is solely the observable thing you mentioned. Then the problem is, how can the algorithm tell apart a simple stream and a complex linear pattern?

Kert commented 5 years ago

Well obviously usually spacing between objects in a stream is so small that the next object is always observable thus the problem is solved by itself. What do you mean by 'complex linear pattern' by the way? If you mean a linear sequence of objects but with a much higher BPM (less time to react) then yeah it still gives 0 where in reality it probably should not? But then again will this be about reaction instead of memory?

MBmasher commented 5 years ago

Complex linear patterns such as in this map https://osu.ppy.sh/beatmapsets/12909#osu/48098

Kert commented 5 years ago

Sounds like it requires the same algorithm that we don't have for Reading skill. e.g. rating patterns of objects in advance by complexity

MBmasher commented 5 years ago

i think a quick fix for streams would be to check consecutive notes, if they had similar distance and angle then it would be detected as a stream and those could be nerfed

abraker95 commented 5 years ago

We can detect linear patterns (a path) by taking a few notes, doing a linear regression, and comparing the r-value against a threshold. To get the full isolated path, do a sliding window with this and stop when the r-value indicates it's no longer a linear pattern. For that path, we can measure how curvy it is as a rough indication of how geometrically complex it is. It would also be helpful to be able to detect path overlaps like the one present at around (a=1.04, a=1.35) in the example, and integrate that into geometric complexity as well.

MBmasher commented 5 years ago

it should also take distance into account, since linear paths with random distance between each note is much harder than a stream

abraker95 commented 5 years ago

Geometrically, varying distance between notes in a linear path is not that hard to read. I can do SOLO on Joint Struggle pretty well with RX, and the only parts that throw me off are the ones that require more agility. However, there is definitely a greater reading aspect for tapping, and to take care of that I first have to finish the rhythmic complexity theory I am working on to exclude physical influence.

abraker95 commented 5 years ago

Is some one willing to work on this? I'll prob not get around doing this until summer due to school work.