Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. Beatmaps
  3. Mapping Discussion
  4. Ranking Criteria
  5. Finalized/Denied Amendments

[Rule Change] Add margin of error to the rule on unsnapped notes

posted
Total Posts
24
Nifty
902 posts
Joined September 2014
Topic Starter
Nifty
"If objects cannot be snapped using the editor’s supported beat snap divisors, a change in BPM must be used to accommodate for it. Objects cannot be unsnapped."

I propose a change to the following:

"If objects cannot be snapped using the editor’s supported beat snap divisors, a change in BPM must be used to accommodate for it. This does not apply to objects that fall within the margin of error. Otherwise, objects cannot be unsnapped."

Along with this should be a new definition in the timing glossary for "margin of error," and I propose it to be as follows:

"Margin of error: When an object is unsnapped by less than 3 ms of its original snapping due to rounding errors in the editor, and does not cause any unintended gameplay change. This does not include the beginning and ends of kiai times."

I believe this should be added to the General RC to avoid unnecessary pops and disqualifications over what is usually a non-issue. Unsnaps that are kiai lines or place a note before its affecting slider velocity or timing line would not be protected by this, as that disturbs the intended gameplay.

This is already believed to be common sense by several bns, qat, and maps have been ranked under the argument that unsnaps under 3 ms do not disturb gameplay in any noticeable way. See https://osu.ppy.sh/beatmapsets/754985/discussion#/201492 and https://osu.ppy.sh/beatmapsets/744587/discussion/1569894/timeline/resolved?user=5256495 for details.

Please feel free to re-word the suggestions since I'm not expert at communication, I just think giving this leeway to mappers and bns alike will make everybody's lives a bit easier.

Note: changed 5 ms to 3 ms.
Last edited by Nifty , edited 3 times in total.
[Zeth]
319 posts
Joined March 2017
[Zeth]
imo it depends btw, if the map has ZERO SV what-so-ever, then allowing margin of error for snapping errors is fine, but i think you should add this statement :

If the note lands on a barline, on an inherit timing point for slider velocity changes/volume changes and/or on a timing point, it must be snap correctly onto the snap divisor.

Since for a lot of times when I'm looking on a map, a lot of sv changes are ruined due to unsnapped notes cause by rounding errors and/or copy pasting some certain patterns in the song, causes the sv to be either sudden or not correspond to the note it should be applied on, so yeah i think adding that statement is quite important.

Otherwise i think this is pretty fine addition to the rules and it would help everyone that does modding/nomination/mapping easier
Last edited by [Zeth] , edited 1 time in total.
Nifty
902 posts
Joined September 2014
Topic Starter
Nifty
Zeth: "Unsnaps that are kiai lines or place a note before its affecting slider velocity or timing line would not be protected by this, as that disturbs the intended gameplay."

That's what this is for.
clayton
1,928 posts
Joined November 2013
clayton
while I agree that up to 3ms is no big deal (and nobody would realistically notice it when playing), this rule just seems like an excuse to not thoroughly find and fix issues within a map

why allow for less accuracy when it's not difficult to snap notes all the time? I read both of those discussion threads, and to be honest, almost all of the people replying to Fouriose base their argument on "it's not worth fixing, because nobody can notice it". it's just a really lazy attitude, imo

the one case where I can see this making sense is where the song does have very minor timing changes (e.g. live performances), and notes are displaced from their snaps to account for it
Nifty
902 posts
Joined September 2014
Topic Starter
Nifty
Clayton: I wouldn't necessarily say calling something unnecessary is being lazy. It truly is that; unnecessary, and why would anybody want to do any more free work than they're already doing? The change isn't only to make mapping and checking less aimod reliant, but also to avoid unnecessary dqs and pops on the account of unsnapped notes. It it a bug that notes can unsnap after a nomination, it's happened to me personally (in mine and others' maps), but I don't have any way of reproducing it so it's not a "proven bug."
clayton
1,928 posts
Joined November 2013
clayton
the approach here should be to fix the relevant bugs and avoid the snapping issues in the first place, not to let them be and ignore the results
Naxess
Nomination Assessment Team
390 posts
Joined March 2016
Naxess
Rounding errors have been a thing since osu started and are relatively well known compared to other bugs, but this hasn't been fixed and likely won't be fixed until lazer, as the current client is not being worked on anymore. If anything this will probably be fixed in the new editor.

As far as aimod inaccuracies go, even if it were completely accurate and found every single unsnap, and the rule forced you to fix all of them, it would be pretty unintuitive to run a third party program every time you make a change to a map, for example by copying multiple objects or changing some SV, to see whether or not some object became unsnapped. You wouldn't even be able to notice it in the editor or gameplay at all unless you went over each note manually and tried snapping them into place.

Forcing people to use third party programs as commonly as that for such a minor adjustment is not something we want mappers to have to do, hence the agreement that things like 1 ms unsnaps are tolerable, even if you could probably snap them anyway once you notice them.

For a step by step reproduction, try this:
  1. Download https://osu.ppy.sh/b/1241508
  2. Go to [Hard]
  3. 01:15:997 (1,2,3,4,1,2,3,4,1,2,3,4) - delete these
  4. 01:11:906 (1,2,3,4,1,2,3,4,5,1,2,3) - copy these
  5. 01:15:997 - paste them here
  6. 01:18:725 (1) - is now unsnapped by 1 ms
  7. Note how 01:14:634 (1) - , which is what you copied, was not unsnapped.

How does this work in practice? Take this currently qualified map: https://osu.ppy.sh/beatmapsets/740862
Now I'm going to paste my wip aimods' results of >=1 ms unsnaps from Hailie's diff into a box. Every single difficulty in the set has 1 ms unsnaps. This is how common they are, and this isn't even the only set with them. I had to actually search for beatmaps that didn't have them, in qualified, to find any. If someone would like to go around dqing all the maps in qualified for this be my guest.
Unsnaps
Unsnapped hit objects.
00:12:144 (2) - Slider head unsnapped by -1 ms.
00:16:827 (2) - Slider head unsnapped by -1 ms.
00:17:266 (3) - Slider head unsnapped by -1 ms.
00:35:266 (1) - Slider head unsnapped by -1 ms.
00:42:876 (2) - Slider head unsnapped by -1 ms.
01:10:388 (1) - Slider head unsnapped by -1 ms.
01:11:266 (2) - Circle unsnapped by -1 ms.
01:12:144 (4) - Circle unsnapped by -1 ms.
01:27:949 (3) - Slider head unsnapped by -1 ms.
01:29:705 (3) - Slider head unsnapped by -1 ms.
01:35:266 (2) - Slider head unsnapped by -1 ms.
02:05:266 (3) - Circle unsnapped by -1 ms.
02:06:144 (5) - Circle unsnapped by -1 ms.
02:09:949 (3) - Circle unsnapped by -1 ms.
02:10:827 (5) - Slider head unsnapped by -1 ms.
02:11:266 (1) - Circle unsnapped by -1 ms.
02:12:144 (3) - Circle unsnapped by -1 ms.
02:24:144 (4) - Slider head unsnapped by -1 ms.
02:28:827 (4) - Slider head unsnapped by -1 ms.
02:29:705 (6) - Circle unsnapped by -1 ms.
02:42:582 (3) - Circle unsnapped by 1 ms.
02:45:801 (4) - Circle unsnapped by 1 ms.
02:46:094 (5) - Circle unsnapped by 1 ms.
02:48:435 (5) - Circle unsnapped by 1 ms.
02:51:655 (2) - Slider head unsnapped by 1 ms.
02:52:533 (4) - Circle unsnapped by 1 ms.
02:54:582 (3) - Slider head unsnapped by 1 ms.
02:55:460 (5) - Circle unsnapped by 1 ms.
02:56:338 (2) - Slider head unsnapped by 1 ms.
02:57:216 (4) - Circle unsnapped by 1 ms.
02:58:094 (1) - Slider head unsnapped by 1 ms.
03:01:021 (2) - Slider head unsnapped by 1 ms.
03:01:899 (4) - Circle unsnapped by 1 ms.
03:07:460 (1) - Slider head unsnapped by 1 ms.
03:08:338 (3) - Slider head unsnapped by 1 ms.
03:13:021 (4) - Slider head unsnapped by 1 ms.
03:13:899 (6) - Slider head unsnapped by 1 ms.
03:14:777 (1) - Circle unsnapped by 1 ms.
03:15:655 (4) - Slider head unsnapped by 1 ms.
03:16:094 (5) - Slider head unsnapped by 1 ms.
03:25:021 (3) - Slider head unsnapped by 1 ms.
03:25:460 (5) - Slider head unsnapped by 1 ms.
03:26:777 (3) - Circle unsnapped by 1 ms.
03:28:533 (4) - Circle unsnapped by 1 ms.
03:35:705 (2) - Circle unsnapped by -1 ms.
03:39:071 (3) - Slider head unsnapped by -1 ms.
03:40:827 (3) - Slider head unsnapped by -1 ms.
03:47:850 (2) - Circle unsnapped by 1 ms.
03:50:777 (3) - Slider head unsnapped by 1 ms.
03:51:655 (4) - Circle unsnapped by 1 ms.
03:52:533 (2) - Circle unsnapped by 1 ms.
03:54:289 (1) - Slider head unsnapped by 1 ms.
03:55:167 (2) - Slider head unsnapped by 1 ms.
03:55:460 (3) - Slider head unsnapped by 1 ms.
03:58:972 (1) - Slider head unsnapped by 1 ms.
04:01:021 (4) - Circle unsnapped by 1 ms.
04:01:899 (2) - Circle unsnapped by 1 ms.
04:03:655 (1) - Slider head unsnapped by 1 ms.
04:04:533 (2) - Slider head unsnapped by 1 ms.
04:07:021 (4) - Slider head unsnapped by 1 ms.
04:08:338 (1) - Circle unsnapped by 1 ms.
04:13:021 (1) - Circle unsnapped by 1 ms.


As for the proposal itself, "This does not include kiai times" seems a bit unclear, do you mean it does not apply in kiai or do you mean that it does not apply for lines that initiate kiai? In either case it seems a bit strange, would probably remove that. Could use the margin of error in the snapping kiai guideline rather than making an exception in the definition.

Also after a bit of experimentation I believe even lowering the leniency to within 2 ms would be reasonable (so that >=3 ms becomes unrankable, this seems to be what you wrote later in the post so maybe that was a mistake? Could also be that I misunderstood "within", "less than or equal to" would be more clear perhaps), rest looks alright.
Last edited by Naxess , edited 1 time in total.
Aiseca
451 posts
Joined February 2017
Aiseca
Unsnapped objects can also happen when creating streams using slider. At first, visually, it's unnoticeable and on autoplay it seems to work well. However, on actual gameplay, these minor ms (especially when those delays soars up to more than 5ms) delays causes wrong feedback on players on how fast or slow they'll engage a certain part of the song. AImod has probs.

Ex. In Editor, this stream (was made using sliders) looks like doesn't even have any issues....

however when zoomed in, that's where it can be clearly seen that these stream was actually unsapped 20ms late.


clayton wrote:

I read both of those discussion threads, and to be honest, almost all of the people replying to Fouriose base their argument on "it's not worth fixing, because nobody can notice it". it's just a really lazy attitude, imo


Firstly, the job of mapping a beatmap doesn't end with just making it and getting it ranked. And people with a mindset that "it's not worth fixing, because nobody can notice it" makes me trigger a lot.
Why?
Because players who are aiming to get better at accuracy can get screwed by these kind of faulty mapsets that fails to check the kind of errors particularly snapping notes. And as a rhythm game, (I am reminding you people, osu is a rhythm game, not intuition feel the rhythm game) being unable to ignore these seemingly small 'unnoticeable' ms delays are actually fatal (on a few cases, this is true).

Second, if laziness to fix these unsnaps is the common denominator of reason, then I should ask them this: Why ........... bother making and trying to ranking a half-baked beatmap at the first place? They may have weird reasons, but for me, it is just illogical.
Why would you be lazy to correct things up, sit for a few sessions and snap those objects correctly when you haven't felt lazy (mapping slow pace is excluded, cause it is understandable) bothering running at queues asking for mods, buzzing at BNs to get a check and stuff, then at the end--- just felt lazy all of a sudden?

Note: These were only my responses based on the things at hand and as far as I can read available at this thread.

Naxess wrote:

Rounding errors have been a thing since osu started and are relatively well known compared to other bugs, but this hasn't been fixed and likely won't be fixed until lazer, as the current client is not being worked on anymore. If anything this will probably be fixed in the new editor.


Well, hope an upgrade will dawn at the ancient AImod.

Naxess wrote:

As far as aimod inaccuracies go, even if it were completely accurate and found every single unsnap, and the rule forced you to fix all of them, it would be pretty unintuitive to run a third party program every time you make a change to a map, for example by copying multiple objects or changing some SV, to see whether or not some object became unsnapped. You wouldn't even be able to notice it in the editor or gameplay at all unless you went over each note manually and tried snapping them into place.


About this tho, it seems to me that even if you do run third party programs and carefully perfect object snapping, the broken editor somehow will make magical overwrite and randomly spawn hidden problems within the mapset during tweaking or saving without the mapper's knowledge.

Naxess wrote:

As for the proposal itself, "This does not include kiai times" seems a bit unclear, do you mean it does not apply in kiai or do you mean that it does not apply for lines that initiate kiai? In either case it seems a bit strange, would probably remove that. Could use the margin of error in the snapping kiai guideline rather than making an exception in the definition.


--Same thought, it will cause ambiguity. And... why exclude Kiai time? MOR is preferred method to use.

Naxess wrote:

Forcing people to use third party programs as commonly as that for such a minor adjustment is not something we want mappers to have to do, hence the agreement that things like 1 ms unsnaps are tolerable, even if you could probably snap them anyway once you notice them.

Also after a bit of experimentation I believe even lowering the leniency to within 2 ms would be reasonable (so that >=3 ms becomes unrankable, this seems to be what you wrote later in the post so maybe that was a mistake? Could also be that I misunderstood "within", "less than or equal to" would be more clear perhaps), rest looks alright.


This is an acceptable error parameters I think. I support this.
1-3 objects with less than 3ms error is tolerable, but I would like just to add a limit to how long the delay is tolerable acceptable: about 5 contigous objects max I think is okay.
Last edited by Aiseca , edited 2 times in total.
Okoayu
Nomination Assessment Team / Elite Nominator
4,959 posts
Joined May 2012
Okoayu
The note snapping is integers anyways, if it was to be 'actually accurate' you'd need to use floats with infinite precision, the beat meter is only given as a float of a certain accuracy so you'll use accuracy over time even if the song is completely true to its bpm as long as the time for a 1/1 beat was rounded in some way

that way it's possible that offset shifts even though bpm doesn't change, this is possible right now, over prolonged periods of time with little to no relevance to most people. In the same vein, something being 1ms earlier or later doesnt really seem worth fixing because the way osu stable internally rounds the position of objects in the timeline differs by just that amount +/- depending on how the meter of the beatmap adds up at any given point

from a mechanical standpoint allowing this stuff to exist makes sense, because neither value is actually correct, both are estimates rounded to the next full number which is causing the difference in the first place

The proposed wording for "allowing" this is super convoluted and doesnt even cover that kiai times are pointed out as technical errors if they're off by just 1 ms according to aimod. the rest of the definition could go into the one rule it is suggesting to use

sliderends behave differently than sliderheads on the matter and will point out earlier as technically faulty. i dont think the leeway should be 3ms or anything in that range, but 1ms if at all. Because the difference of 1ms can be logically attributed to a rounding error, the rest is probably human error
clayton
1,928 posts
Joined November 2013
clayton

Okoratu wrote:

i dont think the leeway should be 3ms or anything in that range, but 1ms if at all. Because the difference of 1ms can be logically attributed to a rounding error, the rest is probably human error


exactly. it's not a snapping issue if it's less than 1ms off (because the osu! file format only specifies time as an integer), but anything more can be fixed, and I see no reason to ignore this issue, especially on basis that "You wouldn't even be able to notice it", or it requires a tedious check

Naxess wrote:

Rounding errors have been a thing since osu started and are relatively well known compared to other bugs, but this hasn't been fixed and likely won't be fixed until lazer, as the current client is not being worked on anymore. If anything this will probably be fixed in the new editor.


I see your point, being that a proper method to fix these issues could be pretty far off. However, after a bit of searching, I found not a single bug report properly detailing this problem (the only related issues were years old, and concerning other specific rounding errors not quite related to copy/pasting). Y'all have to actually report issues if you find them, people don't just magically know

fwiw, the original intention regarding handling copy/paste timing offsets was just to fix them when they happen. it's the reason that AIMod checks for snaps over 2ms off.

mm201 wrote:

[timing offsets] *could* still compound if you do lots of copy/pasting, but I guess AImod would catch that.


Naxess, almost your whole post can be boiled down to "it takes a lot of effort to fix, and the results are barely noticeable", which I completely disagree with. there is a clear, simple method to fix offsets of over 1ms. for now, it's pretty tedious, unfortunately---but I see no reason for that to be justification for making a rule that says "inaccuracy is allowed"
realy0_
1,737 posts
Joined August 2016
realy0_
maybe you should exclude unherited timing points (greens lines) that have a negative ms as they are already executed before obj have a sv/hs changes (green line unsnapped by -2ms doesn't change anything, it act like it's was actually snapped but 2ms unsnap changes does)

may be a bit off-topic but still relevant
Nifty
902 posts
Joined September 2014
Topic Starter
Nifty
In response to some of the things I've seen here.

Naxess: Cleared up some language. I think it's important to make sure the "kiai starts/ends cannot but unsnapped" rule cannot be broken under this rule, so to avoid confusion and needless jumping around the rc, I included it here. Also that rule is actually useful since I've heard that it causes issues with the osu cookie and some other weird things in gameplay.

Aiseca: Unsnapped greenlines before the notes, unnecessary redlines after the map is finished, volume conflicts with redlines and greenlines on the same timestamps; these are all acceptable under the premise that "it's not worth fixing because it's not noticeable in game." I see no reason for a 2 ms unsnap to fall under that category as well. Also, if you look at this post on the timing windows for osu, you'll see the most precise one in the game (like 16ms) is not affected by a note being 2ms early or late.

Also, you probably wouldn't understand the checking 5 (or more) difficulties of a 3 minute set, modding the spread, modding the pattern usage and the aesthetics, suggesting hp and od values, making sure that the bg is rankable, the diffnames make sense, the mp3 is within the kbps limit, the tags are related to the song, discussing one or more of these things with other people for hours to days, then nominating the map just to realize you forgot to open AImod on one difficulty and the set gets dqd for an unsnapped note. Then, according to the BN rules, you have to recheck the entire set. This happens quite often, and I don't think anybody should be against making the job of someone who volunteers hours and hours of this type of work every week a little bit easier.
Aiseca
451 posts
Joined February 2017
Aiseca

Nifty wrote:

In response to some of the things I've seen here:

Aiseca: Unsnapped greenlines before the notes, unnecessary redlines after the map is finished, volume conflicts with redlines and greenlines on the same timestamps; these are all acceptable under the premise that "it's not worth fixing because it's not noticeable in game." I see no reason for a 2 ms unsnap to fall under that category as well. Also, if you look at this post on the timing windows for osu, you'll see the most precise one in the game (like 16ms) is not affected by a note being 2ms early or late.


---- On this particular matter being the argument has been debated long ago, It seems to me that my comments were no longer needed. I would like to state my defense, however, being it misaligned to the current issue we tackle, I'll refrain from doing so.

Nifty wrote:

Also, you probably wouldn't understand the checking 5 (or more) difficulties of a 3 minute set, modding the spread, modding the pattern usage and the aesthetics, suggesting hp and od values, making sure that the bg is rankable, the diffnames make sense, the mp3 is within the kbps limit, the tags are related to the song, discussing one or more of these things with other people for hours to days, then nominating the map just to realize you forgot to open AImod on one difficulty and the set gets dqd for an unsnapped note. Then, according to the BN rules, you have to recheck the entire set. This happens quite often, and I don't think anybody should be against making the job of someone who volunteers hours and hours of this type of work every week a little bit easier.


----I am fully aware of the duties and responsibilities (as described by [Here and Here] and other things undocumented) BN, QAT and alike.

Do not assume that my response reflect in general. What I meant on my comment appeared was pointing out to 'refusing to correct what must be corrected because of laziness' and not because of acceptable circumstances (ea. no fatal consequences even if remained the same, provided that it was given a green light to leave it as it is).

Side note
███████████████████████████████████████████████████████████████████████████████████████.███████████████████████████████████████████████████████████████.████████████████████████████████████████████████████████.████████████████████████████████████████████████████████████.████████████████████████████████████████. Please take time to understand certain angles of an argument and have a broad perspective on things.

P.S. Don't assume things too early and be open to suggestions if you want progression.



Note: Edited.
Last edited by Aiseca , edited 6 times in total.
clayton
1,928 posts
Joined November 2013
clayton

Nifty wrote:

[...] This happens quite often, and I don't think anybody should be against making the job of someone who volunteers hours and hours of this type of work every week a little bit easier.


as I wrote already above, this seems like a completely backwards approach, and it's not making the job of BNs easier, it is making their job less extensive. a real fix here would involve making the job of BNs easier by providing proper tools and methods to deal with this issue

if it helps to make a comparison, then for example... metadata checks are equally tedious and non-rewarding. I really doubt that 99% of cases of slightly-incorrect metadata would result in complaints from any player---but that doesn't mean it's not important, because those tedious checks are what result in the amazing consistency that makes a system good

why it is suddenly "okay" to have margins of error is beyond me. this proposal seems like one big "I give up" because the few people whom have looked into the issue found no solutions
Naxess
Nomination Assessment Team
390 posts
Joined March 2016
Naxess

clayton wrote:

why it is suddenly "okay" to have margins of error is beyond me. this proposal seems like one big "I give up" because the few people whom have looked into the issue found no solutions
It's not that it's suddenly okay and people have given up, it's that it has always been regarded this way, which explains why basically every single beatmap in qualified has 1 ms unsnaps, and haven't been disqualified. What this does is less of a change and more of a clarification on what exactly we deem fine and what is too much.

Regarding this issue not being reported, refer to the thread you quoted from, where peppy basically uses the same reasoning you dislike, it practically making no difference. The in-game aimod also intentionally has leniency built in, meaning 1 ms unsnaps are undetectable. The same applies to third party programs like Modding Assistant, meaning it is impossible for people to find these effectively, unless you make your own program for it like I did. Providing tools for it is more of a band aid fix and third party reliance like I mentioned previously.

So in summary, 1 ms unsnaps are already accepted; this is basically just a clarification of what the exact leniency should be. As for the idea that 1 ms unsnaps should not be allowed because they're imperfections, it would be unreasonable to expect people to fix things they can't even check for reliably in-game, much less check at all.

Pretty sure the only way we could completely throw away the leniency (i.e. disallow 1 ms unsnaps) would be if the bug causing the rounding errors would be fixed, but until then we need to adapt to the way the game works currently, in order to fulfill the goal of making the Ranking Criteria accessible to modders and mappers alike.

Okoratu wrote:

The proposed wording for "allowing" this is super convoluted and doesnt even cover that kiai times are pointed out as technical errors if they're off by just 1 ms according to aimod. the rest of the definition could go into the one rule it is suggesting to use
Oko has a point with this. Could do it something like this, where the added part is in italic, and thereby remove the need for a glossary definition:
Objects must be snapped to timeline ticks. Unsnaps of up to 2 ms due to rounding errors are acceptable. If objects cannot be snapped using the editor’s supported beat snap divisors, a change in BPM may be used to accommodate for it. If a section of music requires an unsupported beat snap divisor however (1/5, 1/7, etc.), a map's objects can be unsnapped so long as they align with the intended beat snap divisor.
(Could possibly even do "1 ms unsnaps due to rounding errors are acceptable", considering how rare 2 ms unsnaps are, although they can technically happen the same way as 1 ms ones on stuff that is already unsnapped by 1 ms)

The kiai guideline that is already in place doesn't really mention anything about snapping, so there shouldn't be any need to change or make exceptions for that, as it is more of a general idea of how kiai should be used:
Kiai should start on a sound in the music. Doing so otherwise causes the kiai flash to feel unrelated to the song.
clayton
1,928 posts
Joined November 2013
clayton
@Naxess: I know that 1ms is unreasonable to fix at the current time (because the file format does not really allow for it), and I mentioned so at the beginning of my second-to-last my post by agreeing with Oko. what I am suggesting is that further timing errors, i.e. the ones pointed out by AIMod, are properly addressed& fixed, because at that point any osu! mapper could spend a few minutes re-snapping sections that were copy/pasted or moved in ways that caused timing errors

for the sake of making sure I'm not making a ridiculous claim, I applied random +-3ms offsets to an old 4-minute Insane diff of mine, and it took just under 10 minutes to get the map back to its original state, using the editor alone. it was tedious for sure, but it's not a huge favor to ask when it means that the map will be undoubtedly more correctly timed

I would appreciate if you could argue against my belief that this issue is no more than "it takes a lot of effort to fix, and the results are barely noticeable" (quoted from my earlier post), because that's the part I really disagree with. sorry that my tone sounds like I'm not on your side about this, I just feel like nobody in favor of this proposal has responded to the most important part of my argument yet
Okoayu
Nomination Assessment Team / Elite Nominator
4,959 posts
Joined May 2012
Okoayu
This sort of behaviour was once in stable aimod for a tiny bit, if this should make it i would suggest bringing it back

If no one's against it I'd push the 1ms unless someone gives me an example of a 2ms unsnape

(i suppose naxess can given he has done stuff with some sort of aimod)
pishifat
osu! Paragon
3,812 posts
Joined August 2013
pishifat

Okoratu wrote:

If no one's against it I'd push the 1ms unless someone gives me an example of a 2ms unsnap


there's a few ranked maps with 2ms unsnaps on reverses of reverse sliders. examples:
https://osu.ppy.sh/s/848259 - 03:08:810 on hard
https://osu.ppy.sh/s/645657 - 02:01:045 on normal
https://osu.ppy.sh/s/308238 - 00:15:596 00:17:247 00:17:797 00:21:099 01:34:840 01:36:491 01:38:142 01:41:444 on hard, 01:32:639 on medium

reverses don't show as unsnapped in aimod, but the tail will show up as unsnapped if you remove the reverse. it's unreasonable to remove the reverse of every slider to check if it's unsnapped though, so i'd rather fix aimod before deciding a cutoff
Lumenite-
631 posts
Joined April 2015
Lumenite-
i don't see how rounding errors would increase/decrease an integers value more than up/down 1 whole number. along with that, i agree greatly with clayton that the approach to something like this is fix bugs and avoid snapping issues at all. granted the ladder option is extremely difficult to do, i still don't think that 3ms is a logical margin of error at all. as aiseca mentioned in their post, those tiny things that might not seem like a big deal may actually be a big deal and damage the gameplay experience in a few cases. 1ms is enough for a "margin of error," especially if as i said earlier this is based on the editor. if you're moving around un/inherited sections, you should know to move notes to be snapped correctly anyways.
Aiseca
451 posts
Joined February 2017
Aiseca

incandescence wrote:

i don't see how rounding errors would increase/decrease an integers value more than up/down 1 whole number. along with that, i agree greatly with clayton that the approach to something like this is fix bugs and avoid snapping issues at all. granted the ladder option is extremely difficult to do, i still don't think that 3ms is a logical margin of error at all. as aiseca mentioned in their post, those tiny things that might not seem like a big deal may actually be a big deal and damage the gameplay experience in a few cases. 1ms is enough for a "margin of error," especially if as i said earlier this is based on the editor. if you're moving around un/inherited sections, you should know to move notes to be snapped correctly anyways.


Large sums of unsnap errors on hitobjects (especially circles on standard) are fatal on one or a combination of these variables, I assume (on Mania and Standard game modes). I'm not sure on other game modes tho]:
  1. Players using mods [, [HR, SD, DT/NC and particularly PF]
    ex. Highest diff on a ranked beatmap with DT mod on

    If you only have +-13ms window time to score 300, then 2ms and above unsnaps is bad... That'll leave you +- >10ms to get a 300, much more difficult on jump sections.
  2. Spaced stream sections of a song on an average~high BPM songs. []
    *spaced referring to Standard mode.
  3. Readability vs feedback issues for Starters [mainly Easy to Normal diffs of ]
  4. Note rain/ barrage with consistent readable beat. [mainly on ]
    *Same as #3, but on higher difficulties. Can be applied to Standard.
  5. Songs with irregular (swing?) or varying (speed) rhythms in a succession. [highly fatal on both if #1 is active on this scenario]



pishifat wrote:

Reverses don't show as unsnapped in AImod, but the tail will show up as unsnapped if you remove the reverse. it's unreasonable to remove the reverse of every slider to check if it's unsnapped though, so i'd rather fix AImod before deciding a cutoff


Fixing AImod......sounds good~~ :)
pishifat
osu! Paragon
3,812 posts
Joined August 2013
pishifat
aimod detecting reverses has been fixed and will be in an upcoming client update
clayton
1,928 posts
Joined November 2013
clayton
now that's the kind of change I was hoping for. awesome :D
pishifat
osu! Paragon
3,812 posts
Joined August 2013
pishifat
aaaaaand it's ingame now. gonna update the rule to say that unsnap = what aimod points out, which means 1ms unsnaps aren't going to be relevant (and should solve this thread's concern)
show more
Please sign in to reply.

New reply

0
1 / 24