Right now they're summed normally what opens a problem that FL rewards
too much pp when combined with reading map, since you're memorizing FL
anyway.
Co-authored-by: James Wilson <tsunyoku@gmail.com>
This doesn't solve _flow_ aim in any way, but makes it so that `Speed`
doesn't have distance scaling (read as "aim") anymore which fixes some
issues related to that like the length bonus behaving incorrectly, and
in general `Speed` being an aim+tap skill instead of just a tapping
skill
---------
Co-authored-by: James Wilson <tsunyoku@gmail.com>
This PR aims to replace the current bonuses used to award high approach
rates and scores made using the Hidden mod with a Reading skill that
takes into account each note's reading difficulty separately, Important
to note is the fact that as reading difficulty is now a skill the
bonuses are now additive instead of multiplicative, meaning there are
vast changes in deltas on the high and low end of scores. Due to the
nature of adding a new skill new difficulty and performance attributes
need to be added.
Huis page:
[https://pp.huismetbenen.nl/rankings/admin/kwotaq-reading](url)
---------
Co-authored-by: apollo-dw <83023433+apollo-dw@users.noreply.github.com>
Co-authored-by: js1086 <js1086@student.le.ac.uk>
Co-authored-by: tsunyoku <tsunyoku@gmail.com>
Co-authored-by: StanR <hi@stanr.info>
Currently the slider bonus works on the assumption that the travel
velocity of the previous slider is a part of the current object's
difficulty because it is part of the movement from prev to curr.
However, this is contradicted by the fact that `currVelocity` is a
combination of prev->curr + curr slider velocity and is actually
breaking the assumption that slider difficulty is contained in the
slider itself that we take when calculating difficult slider strains.
This makes it so that the slider bonus difficulty is contained in the
slider itself instead of buffing the next object, which makes both the
calculation overall more consistent and the slider factor calculation
actually work as expected.
Aim multiplier got slightly lowered because this change makes most of
the sliders gain a little bit
---------
Co-authored-by: James Wilson <tsunyoku@gmail.com>
## This pr resolves the issue with the angle calculation.
The old system calculated the angle between three objects. If the last
object was a long slider that the player needed to follow, the system
calculated the angle using only the slider’s end point and the previous
object, which caused long sliders to have incorrect angle values.
---------
Co-authored-by: StanR <hi@stanr.info>
Co-authored-by: James Wilson <tsunyoku@gmail.com>
The purpose of this change is to remove the arbitrary note based length
bonus for speed and replace it with a more concrete per note difficulty
aware calculation. As a result of the summation needing to be per-note,
chunking and in consequence peak strain reduction have both been removed
from the skill. ~~The various strain counting functions also heavily
relied on chunking and the way summation worked, so they have also been
changed to match values held before the change as much as possible
(given the different summation some changes in values are bound to
happen).~~ Above was a bug.
Huis page:
[https://pp.huismetbenen.nl/rankings/players/length-bonus](https://pp.huismetbenen.nl/rankings/players/length-bonus)
---------
Co-authored-by: James Wilson <tsunyoku@gmail.com>
This PR moves the influence of d/t^2 from the skill (through strain)
directly into the evaluator level as a bonus applied at the end. This
makes it more clear what d/t^2 is, and the fact that it applies to *all*
bonuses in the evaluator. As well, the peak strain value of a note is
now equal to the evaluator value. This comes with a couple benefits:
1. The BPM weight is now subject to balance, and can be flattened easily
for a more "d/t" like system (previously this required hacky solutions)
2. StrainDecayBase becomes a much more useful variable now that it does
not affect the difficulty of the note itself. When adjusting this in
live, your star rating would double upon changing from 0.15 in aim to
0.3, and now it is intuitive what it does (makes strain take longer to
accumulate). This means that future balancing efforts can use evaluators
to dynamically adjust strainDecayBase (potentially letting large spikes
provide more strain for the same difficulty if they're wide angle, for
example).
3. In the object inspector, you get the actual maximum difficulty value
of a note as seen in the ObjectDifficulties list. This makes it easier
to tell what notes are deemed as harder by the system. For context,
previously, a note of difficulty 1 at 200bpm would cap out at 6 as a
result of strain, and a note of the same difficulty but at 300bpm would
cap out at 8.
The actual implementation is really really simple. I'm willing to move
this to flashlight if wanted (I don't think it's necessary), or even
abstract this away so that (1 - decay) doesn't look like a balancing
constant.
Side note: this is equivalent to live, except for notes with a deltaTime
of less than 25ms (since I am using AdjustedDeltaTime in the aim
evaluator for the bonus to avoid divisions by zero).
It's a common mistake by newer pp dev contributors to increase the
wiggle multiplier not knowing its at its maximum, so I added a comment
to try to avoid more people doing it.
---------
Co-authored-by: StanR <8269193+stanriders@users.noreply.github.com>
Fun correctness bug.
ScoreV1 multiplier uses the **nomod** peppy stars (i.e the beatmap's
"base" HP, OD and CS) in all cases, which was generally the intention
with this code but it passes the wrong beatmap resulting in it using
modded values for this.
Cross referenced with stable and this now results in the expected
multipliers.
Results in some very minor (<3pp from my testing) changes for HR and EZ
scores with combo breaks.
* Implement new portion formula
* Change the formula
* Use base value of 5 sliders
* Make the threshold harsher
---------
Co-authored-by: StanR <8269193+stanriders@users.noreply.github.com>
* Remove unnecessary information from matchmaking beatmap panel
* Move avatar overlay inside card for better layout
* Allow higher jumping when jumping in succession
* Exclude player panel avatars from masking
* Adjust player panel animations a bit further
* Add avatar-only display mode
* Fix round warmup test not working
* Remove dead test scenes
* Fix edge case where users are added to not-yet-loaded card
* Decouple `PlayerPanel` from `UserPanel`
* Fix remaining test failure (and rename test to match new naming)
I'm not exactly sure on the reproduction scenario here, but I have had
switching ruleset with converts disabled crash on me a few times
today. It appears to happen sometimes when after the switch the expanded
group no longer exists in the set mapping, because a filter just ran and
removed that group from set of possible groups because there'd be no
beatmaps under it.
I tried to manufacture a quick test but it's not a quick one to test
because filtering intereference is required to reproduce, I think.
I will try again on request but I mostly just want to get this fix out
ASAP before I finish up for the day.
Because the detached store exists and has a chance to actually
semi-reliably intercept a beatmap update operation, I decided to try
this. It still uses a bit of a heuristic in that it checks for
transactions that delete and insert one beatmap each, but probably the
best effort thus far?
Notably old song select that was already doing the same thing locally to
itself got a bit broken by this, but with some tweaking that *looks* to
be more or less harmless I managed to get it unbroken. I'm not too
concerned about old song select, mind, mostly just want to keep it
*vaguely* working if I can help it.