hiviexd / mvtaikochecks

A set of osu!taiko Mapset Verifier checks

MVTaikoChecks

A set of osu!taiko specific Mapset Verifier checks

Warning

This plugin is still in active development, so false positives and false negatives may occur. If you find something that isn't right, please refer to the Feature requests & bug reports section.

ALWAYS APPLY YOUR OWN JUDGEMENT ON EVERY CHECK AND DON'T BLINDLY FOLLOW THEM.

Features

BPM scaling

Checks try to compensate for BPM scaling when needed, however this is not perfect and may cause false positives in very high or low BPM maps. Always use your manual judgement with every check.

BPM	Action
BPM <= 110	effective BPM is multiplied by 2
110 < BPM <= 130	effective BPM multiplied by 1.5
130 < BPM < 270	effective BPM is unchanged
BPM >= 270	effective BPM is divided by 2

Important

This unfortunately does not work on double/half BPM-style maps that don't change the actual BPM value, so it will cause false positives.

Available checks

• Double barlines
• Rest moments
• Unrankable finishers
• Abnormal note gaps
• Spinner gap
• OD/HP settings
• Kiai flashes
• Unsnapped last note that accidentally hides its barline
• Pattern lengths
• Inconsistent kiai toggles across difficulties
• Inconsistent background position across difficulties
• Barlines unaffected by SV when they likely should be

Planned checks

• Extreme SV changes/SV jumps in lower difficulties

Installing

1. Download and install Mapset Verifier from here if you don't have it already
2. Download the latest release of MVTaikoChecks.dll
3. Open MV and click the settings icon (top right)
4. Scroll down to the Shortcuts section
5. Click the Open externals folder icon
6. Open the checks folder
7. Close MV and place the MVTaikoChecks.dll file in the folder above
8. Start MV again

Known issues

Difficulties with custom names are always marked as "Easy" so make sure you manually change that to the correct diff, else you'll have an insane amount of flase positives.

Note

This is an issue with Mapset Verifier (specifically the lack of osu!taiko SR calculation), not this plugin.

Mapset_Verifier_HO3VmaTJUV.mp4

Feature requests & bug reports

If you have any feature requests or an issue to report, please open an issue or reach out to one of the active maintainers below:

• Hivie (osu!: Hivie | Discord: hivie)
• Nostril (osu!: Nostril | Discord: nostril)

Contributing

If you're here to contribute, please open an issue to discuss your idea before you start working on it.

Special thanks

• phob144 for being integral to development in early stages

mvtaikochecks's Issues

SV detections should apply to barlines in a similar fashion to notes

Similar to existing base MV checks such as "Hit object is unaffected by a line very close to it." would be appreciated if these can detect barlines too.

Setting custom difficulties to "Expert" by default

initial issue pointed at : #6 (comment)
I believe this should cover most cases usage without having to manually change the top diff to expert

Remove break length BPM scaling from `RestMomentCheck`

So going through the code for RestMomentCheck again, I realized this is how we are handling BPM scaling for the check:

1. Scale the minimum gap for what's an acceptable rest moment (lower BPM => more forgiving)
2. Scale the amount of continuous mapping w/o break (lower BPM => less forgiving)

I think # 1 makes sense, but do we actually want to be doing # 2?

I feel like often when I'm manually checking for rest moments, I think not scaling the amount of continuous mapping, but only scaling the acceptable break gap, makes sense since song structures still follow conventions like 1 bar = 4 measures, which is 16/1. This seems to be what the RC is built around. I think this is more intuitive so that break structure lines up with song structure.

So I think we should just change this part to use non-normalized msPerBeat, but wanted to confirm this makes sense.

Add a drastic SV change warning for lower difficulties

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

Double barline not being detected

On this map, there is a double barline at 01:08:944 that is not being detected.

Opening this issue to investigate if this false negative can be fixed.

Add inconsistent Kiai boundaries check

Maybe could add a check if the kiai start/end is not consistent across the set (like if the Oni ends a kiai in a different place from the Kantan or something). I've seen this blunder happen pretty frequently when kiai boundaries are adjusted.

I know this is sometimes intentional, particularly on sets with guest difficulties, so I would make it only minor severity.

---

The part that seems tricky for the implementation is the situation where a Kantan GD makes their Kiai intentionally different, but also a host mapped multiple diffs and made a blunder in one of them (let's say, in the host's Oni). In this case, if Kantan GD were used as the reference point - the blundered Oni won't be caught.

To address this, there's a few options:

1. Make this a general check, and sort each unique set of Kiais into groups, then mention all those groups in the check
   • So it would say something like: "Inconsistent Kiai boundaries: "GD'ers Kantan vs Host's Futsuu/Host's Muzukashii vs Host's Oni"
2. Could use regex similar to the CheckGuestTags check to identify each mapper involved and group the diffs by mapper, then just implement the check per-diff and have it compare to their lowest diff
   • However this will make it so if a GD is unintentionally inconsistent with host diff, it won't be caught unless we add some special logic for this (which we could)
   • If we do this approach, I'd be fine with raising the severity to a Warning

Unsnapped barline not being detected?

Honestly I'm not sure why this unsnapped barline is happening in this beatmap. It looks like the green line is on the bar line. Offsetting the barline early fixes the issue. Perhaps it could be due to some hidden decimal values? It's not being detected by MV.

Map Link - Unsnapped barline is seen on top diff @ 03:12:368

Curious if anyone knows why this is happening, and if something like this can be made detectable by an MV check?

check if last note of a map lands on a barline and is snapped 1ms before it

uncommon bug but still happens, and when it does, the barline simply doesn't render which isn't supposed to happen, and will result in a pop/dq

it should be a problem check for notes, and a minor check for slider/spinner ends, because this trick tends to be intentionally used for those which is fine lol

additionally it'd be a good idea to add a TaikoUtils function that checks if a note is close to a barline by ±10ms, and a function that checks if a note is snapped to a barline, both functions could be quite useful fir this check and in the future

Installation instructions could be more clear

Just some quick thoughts maybe can do this later

1. Could use numbered list instead of bullets
2. Could have a brief step for where to get base MV app
3. Following these instructions precisely makes you run into an issue where it won't let you drag in the DLL while the app is running (not sure if this is based on permissions, but I run into this consistently and have seen other users get confused). Maybe add a step to close the app before dragging and then reopen at the end

refactor/rework the unrankable finishers check

current issues:

• very old check and its code is certainly flawed, could really benefit from a revision
• check only works reliably on kantan, futsuu, and muzu difficulties, oni and inner portion really need a rework
• finisher and preceding note same color detection is missing

implement osu!taiko diffcalc

not really sure if this is even possible with a plugin but i remain hopeful

lack of taiko diffcalc is causing the issue where diffs with custom names are always marked as "Easy", which causes an insane amount of false positives, so users have to manually change that to the correct diff, which isn't intuitive nor optimal.

Pattern length check

Particularly in the lower diffs, the RC has guidelines advising patterns of certain snap divisors to not exceed certain lengths.

For example in Futsuu:

1/2 patterns should not be longer than seven notes. Anything longer is likely to be too straining for beginners.

Could be good to emit a minor issue or warning when stuff like this is detected.

Add an unsnapped kiai check

Aimod already has it, and I think it's just kind of annoying having to check both Aimod and MV. So it'd be nice to put it in MV as a central place with everything.

Also not sure if there's other checks which are Aimod only but if so, would be good to copy those over as well.

Found a map with final barline hidden, and seems undetectable?

Ok another weird barline related bug...

This map has its final barline not rendering for some reason, despite the spinner tail being snapped. Resnapping it, or even for that matter replacing it with a different hitobject doesn't seem to fix it.

So needless to say, LastNoteHidingBarlineCheck doesn't catch this, and it seems like something that might've be an issue if the map did end with a circle instead of a spinner? Idk just a very strange anomaly

I'm not sure this is detectable with taiko MV plugin, or what even the mapper would do to fix this since it seems like some weird bug with the game itself, but I figured this might be a good place to start with mentioning it...

Unrankable Finishers Check missing some cases?

I was looking at this map, when I noticed that there were some unrankable Futsuu finishers that weren't being caught by MV for some reason?

Unrankable Futsuu Finishers at 00:37:603

I reviewed the code and not sure why it wouldn't catch this. We should look into it a bit more to debug it.

I'm on a different setup currently so don't have my dev environment but I can check it when I get back. Or if anyone else wants to take a look into it now that'd be cool too.