Unsnapped barline not being detected?

[hongaaronc]

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?

[hongaaronc]

Perhaps implementing #22 may work to detect this?

[Hiviexd]

the native check sometimes doesn't work it seems. thoughts on making our own "ensure this makes sense" check for all unsnapped barlines? should be pretty helpful when checking for unintentional unsnaps, while also making intentional ones ignorable

[hongaaronc]

Investigating this more....

it seems this is caused when the barline is unsnapped (either early or late) by an extremely small amount. It seems that barlines in osu engine use a lower level of precision than hit objects do?

In MV we use double for all timing-related offsets. However, it's possible that osu uses double for hitobjects and some lower precision datatype for barlines?

For instance, try this in the map I posted:

• Add a 5.00x SV at 03:00:368 - only the note gets affected strangely enough
• Add a 5.00x SV at 03:12:368 - same thing...

this is utterly bizzarre.... anyway I think we could detect it by finding an appropriate epsilon to catch this.

[hongaaronc]

Oddly enough...

...these timestamps aren't affected in the same way despite the unsnap being much less. Wtf is happening

It's worth noting though that the affected timestamps are the later ones in the map... I wonder if the barlines accumulate rounding error over the course of the map - like if they are generated relative to the previous ones offset or something? If this is the case we may need a different method of calculating where the barlines are that isn't using modulo (%).

[hongaaronc]

Fwiw.... tested this stuff in Lazer and the issue isn't reproducible there o.O

[hongaaronc]

I don't think we meant to close this issue. But #31 will fix it - we can close it after that PR is merged

[hongaaronc]

I found another case of this on this map @ 02:40:363