Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a drastic SV change warning for lower difficulties #4

Open
Hiviexd opened this issue Sep 28, 2023 · 4 comments
Open

Add a drastic SV change warning for lower difficulties #4

Hiviexd opened this issue Sep 28, 2023 · 4 comments

Comments

@Hiviexd
Copy link
Owner

Hiviexd commented Sep 28, 2023

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:

  • Kantan & Futsuu: more than 0.1 difference
  • Muzukashii: more than 0.2 difference
  • Oni: more than 0.3 difference

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

@Hiviexd Hiviexd added feature request good first issue good starting point for contributing to this project labels Sep 28, 2023
@Hiviexd Hiviexd changed the title Aadd a drastic SV change warning for lower difficulties Add a drastic SV change warning for lower difficulties Sep 28, 2023
@hongaaronc
Copy link
Collaborator

hongaaronc commented Sep 28, 2023

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
Copy link
Owner Author

Hiviexd commented Sep 28, 2023

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

your approach is much more helpful tho

@Hiviexd Hiviexd removed the good first issue good starting point for contributing to this project label Sep 30, 2023
@Hiviexd
Copy link
Owner Author

Hiviexd commented Oct 1, 2023

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
Copy link
Collaborator

hongaaronc commented Jan 18, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants