Hiviexd / MVTaikoChecks

A set of osu!taiko Mapset Verifier checks
3 stars 2 forks source link

Add a drastic SV change warning for lower difficulties #4

Open Hiviexd opened 1 year ago

Hiviexd commented 1 year ago

Feature request

Description

after discussing with a few bns, i figured out that it'd be useful to add this kind of check, drastic sv changes in lower diffs tend to negatively impact readability, or are unintentional. this check would display a warning whenever the difference between 2 green lines is bigger than the thresholds below.

the thresholds that were agreed upon are:

optional: throw a minor warning in Inner Oni diffs when the difference is 0.5 or more, could help with detecting unintentional drastic changes(?)

Difficulties that are covered by this check

Kantan, Futsuu, Muzukashii, Oni

Notes

there shouldn't be a direct comparison between SV multiplies purely, check should account for the BPM of both lines, that way it won't throw false positives for multi-BPM maps

hongaaronc commented 1 year ago

The simple checking for a fixed difference seems a bit naiive, as it would only cover SV jumps. I think this is actually a lot more complicated than it seems on the surface.

It wouldn't cover drastic SV changes if they had an SV Function effect that made these changes distributed over several green lines, even if those green lines were super close to each other.

For example, this won't be able to be detected: This could be a 0.5->1.5 SV acceleration in Oni

In fact, you only need granular green lines between notes to skirt around this - don't even need any notes to be affected. This situation might occur in cases where gradual SVs were copy pasted from a higher diff with more notes to a lower diff, where they result in jump SVs.

So for example, this also won't be able to be detected: This could be a 0.50 -> 0.80 SV jump in a Kantan


What I'm thinking to solve this, is instead of trying to detect the difference from greenline-to-greenline, perhaps we should parse each note and determine which SV is assigned to it, then try to detect the difference note-by-note. This note-by-note check could be similar to the proposed check - so something along the lines of:

SV can't increase more than 0.1 between any two adjacent notes.

For the gradual SV effect case - we could calculate a "rate of acceleration" based on the SV change / # beats since last note and set thresholds based on that. So it could be specified more as something like:

SV can't increase more than 0.1 in a span of 1/1.

I think with those two checks that will cover all cases quite well.

Hiviexd commented 1 year ago

original intention was to just catch sv jumps, i may have worded that badly

your approach is much more helpful tho

Hiviexd commented 1 year ago

one thing that could massively help with this is a utils function that filters out green lines that don't affect any notes sv-wise, that should make a list that's much easier to work with, kinda like what i did with the kiai flashes one

hongaaronc commented 8 months ago

I have thought of some plans to actually make this way more robust - instead of just looking at each SV change as a single element - like a single change between two notes, or a single greenline - I want to introduce parsing that lets MV understand the SV effects as a whole, like a human would. So it would be able to identify SV values that follow linear/exponential/whatever easing function, and record the start/end time of the effect, and the type of easing used.

I think this could allow for this check to be way more robust - like it can handle jumps differently from gradual accelerations. It could detect unexpected values inside an acceleration. It could detect missing SVs due to redline SV reset and stuff like that. It will also make the basic checks just way more cleanly reported (like it will say something like "The SV effect from xx:xx:xxx -> xx:xx:xxx is too drastic" instead of reporting individual notes/greenlines).

I have some ideas on how to implement this and will see if I can do it this weekend or maybe next weekend.