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.
That's what this is for.
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
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.
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.
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.
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.
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
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.
mm201 wrote:
[timing offsets] *could* still compound if you do lots of copy/pasting, but I guess AImod would catch that.
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.
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.
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.
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.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
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: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
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)
Kiai should start on a sound in the music. Doing so otherwise causes the kiai flash to feel unrelated to the song.
Okoratu wrote:
If no one's against it I'd push the 1ms unless someone gives me an example of a 2ms unsnap
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.
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