forum

[Proposal] General timing ruleset draft

posted
Total Posts
30
show more
Kibbleru
can we have something that handles cases where you need to put a slider going through a timing point?

i remember one map (sorry i forgot which one) which it was heavily discussed that there was an unsnapped slider end due to it passing through a red line, but since the timing differences were rather minimal, and its a really unhelpable case, it was accepted and allowed to be ranked.


actually i really just wish peppy made it so that sliders snapped similarly to spinners where it will just snap to a tick your on lol
DakeDekaane

pishifat wrote:

There must not be extra uninherited points in any difficulty. These can affect main-menu pulsing, the Nightcore mod, and cause timing to shift due to millisecond rounding errors.
What about adding uninherited points to make NC mod sound not broken?
Myxo

Kibbleru wrote:

can we have something that handles cases where you need to put a slider going through a timing point?

i remember one map (sorry i forgot which one) which it was heavily discussed that there was an unsnapped slider end due to it passing through a red line, but since the timing differences were rather minimal, and its a really unhelpable case, it was accepted and allowed to be ranked.


actually i really just wish peppy made it so that sliders snapped similarly to spinners where it will just snap to a tick your on lol
That would be awesome, lol, especially if slider ticks would be calculated through the new timing sections, too. But since it's probably not going to happen soon (until osu! lazer I suppose), I'd suggest a rule / guideline about this, too.
Okoratu
wait is the "there must not be extra timing points in any difficulty" prohibiting resetting metronomes which align with downbeats for the sake of having the Metronome count accurate and, on generic songs with weird resets, the shit the NC mod adds line up
Logic Agent

Okorin wrote:

wait is the "there must not be extra timing points in any difficulty" prohibiting resetting metronomes which align with downbeats for the sake of having the Metronome count accurate and, on generic songs with weird resets, the shit the NC mod adds line up
Unless I'm understanding you wrong, that falls under this doesn't it?

pishifat wrote:

Uninherited timing points must be used to accurately map the song's time signatures. If an incorrect time signature lasts for more than one bar, a timing point must be added on the next downbeat to reset the time signature.
Topic Starter
pishifat

Logic Agent wrote:

.
technically it doesn't, but the ubkrc will discuss it/try to make it clearer
Wafu

Kibbleru wrote:

can we have something that handles cases where you need to put a slider going through a timing point?

i remember one map (sorry i forgot which one) which it was heavily discussed that there was an unsnapped slider end due to it passing through a red line, but since the timing differences were rather minimal, and its a really unhelpable case, it was accepted and allowed to be ranked.


actually i really just wish peppy made it so that sliders snapped similarly to spinners where it will just snap to a tick your on lol
I remember these were occasionally handled by editing this value in the .osu file. I think it should be made clear if this is still allowed or not.
Example: 03:24:123 (4) - https://osu.ppy.sh/b/694384

The object in .osu file looked like this:
392,284,204123,2,0,B|344:303|314:295|314:295|253:349|198:323,1,211.5
Changing the last value (211.5) is making the slider longer, so you can calculate the end of the slider or do a trial and error. I personally believe that if there is a slider passing through a timing section, it should be recommended to manipulate this number to get it relatively accurate, if the difference is notable.
Topic Starter
pishifat
alright, closing time

we'll go over your concerns and open back up for another round of discussion soon! thanks!
Topic Starter
pishifat
changelog:
  1. included informal names of inherited/uninherited points in glossary
  2. clarified usage of time signatures unsupported by the editor in the "Uninherited timing points must be used to accurately map the song's time signatures." rule
  3. clarified usage of red lines for nightcore/metronome resets in the "There must not be extra uninherited timing points in any difficulty. rule
  4. clarified how to handle volume/sv changes before the song's first downbeat in the "An inherited timing point cannot be placed before the first uninherited timing point." rule
added 3 rules to account for feedback from evening and kibbleru:
  1. 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.
  2. Objects which are wrongly snapped due to passing through a new uninherited timing point must have their ends snapped within the new timing section. For spinners and osu!mania Long Notes, this can be achieved through dragging an object’s tail in the timeline. For sliders, this can be achieved through slider velocity manipulation or editing of the .osu file.
  3. Objects which are wrongly snapped due to ending slightly before a new uninherited timing point must have their ends snapped to the new timing point. For spinners and osu!mania Long Notes, this can be achieved through dragging an object’s tail in the timeline. For sliders, this can be achieved through slider velocity manipulation or editing of the .osu file.
and various wording tweaks to make things more readable


specific responses:

Evening: Think if you add green line and red line as alternate names in the glossary it'd be good, uninherited timing points and inherited timing points aren't really said that much I believe, kinda makes it confusing and complicated haha
→ added

Doyak: make “timing point” in second sentence “uninherited timing point”
→ fixed

DakeDekaane: What about adding uninherited points to make NC mod sound not broken?
Okorin: is this prohibiting resetting metronomes which align with downbeats for the sake of having the Metronome count accurate and, on generic songs with weird resets, the shit the NC mod adds line up
→ added clarification sentence

Monstrata: A map’s first uninherited point cannot be used to toggle kiai. Doing this will cause the kiai to flash before objects appear. An inherited point in the same position as the first uninherited point must be used to toggle kiai instead. Guessing we will have to mention this when amending the rules about green and red lines having to be consistent.
→ yes

Monstrata: Might be helpful to mention something about anacrusis, and pushing a redline back a measure (or four) if one needs to change the SV/hitsounding/etc... for objects that occur before the first red line.
→ added clarification sentence

Monstrata: Are supercell-like songs single bpm or variable bpm? What about songs that are consistent except for a few sounds?
→ if songs have variations of any kind, they are variable bpm. if they’re like supercell and would be more playable not having red lines to adjust, they fall under what the guideline says

Sonnyc: Besides, using an object before an uninherited point is fine, right?
→ yes

Mako Sakata: Thoughts on negative offsets?
→ they’re ok

Doyak: So now we can use a green line on the same spot with a red line, while the audio setting is different from each other?
→ yes

Doyak: Guideline about timing points during breaks? Main menu pulsing/nightcore reasoning
→ doesn’t affect much so not really worth it. it’s still a valid thing to do if you want though, as labeled in the guideline’s description

Doyak: Some parts on the proposal says just "uninherited points" and "inherited points" without the word 'timing', is this intentional?
→ added timing to all of them

Evening: Universal offset issue: I know there's a function to let you guys set global offset in the map itself, but at what point do you guys dq these
→ universal offset is best used only for ranked maps. if a qualified map has an offset issue and it’s reported, it’ll probably be dq’d

Evening: Disagreement with offset/BPM: Some people have offset/BPM disagreements at times, though they do revolve around the actually correct BPM/Offset, how big of an issue must this be for a DQ to happen
→ an amount that could affect gameplay. for single-bpm songs, anything noticeable should be adjusted, since it only benefits a map. for variable bpm songs, it depends on how timing variations are handled, and whether or not the community thinks an issue (what the guideline explains)

Evening: Note Specific offset issue (Snaps): Some maps require you to do 1/5, 1/24, 1/32, 1/64 and so on for perfect timing of the notes. Technically, they are snapped correctly, but just not supported in the editor, is this a problem? (This is quite important for low BPM maps)
→ rule added about that

Evening: Note Specific offset issue (Offset): Some notes can be mapped to instrumentals that are not snapped at all, but when does it become a snapping issue and when can it be overlooked if people argue that some notes are 1/16 and some people argue that it's 1/12 while there is negligible difference. This is a rather apparent problem when people time vocally snapped maps.
Evening: What about persistent instrumentals with no clear starting point, such as a violin fading in, do we have a larger margin of error?
→ both are essentially what the guideline explains -- depends on a mapper’s reasoning and whether or not the community agrees with that reasoning

Evening: You might want to include a guide on how to know if the BPM should be doubled/halved or when this error isn't a problem. Not too sure but I think there are cases where osu!standard allows doubling/halving bpm for specific intentions, not sure(?)
→ doesn’t really seem appropriate for the ranking criteria, since tutorials aren’t related to this

Evening: Wasn't there problems with specifying some time signatures that the editor doesn't support? think some guidelines on how to workaround would be cool
→ clarified in first rule

Kibbleru: can we have something that handles cases where you need to put a slider going through a timing point?
→ added 2 rules about situations related to that


this will be open for community revision until march 18th!!
TicClick
I'd love if there was anything about accurate time signatures and explicit permission to edit these restricted by UI into .osu (say, 10/4). I'll leave the exact wording up to you, or anyone else.
edit: turns out I can't read
Okoratu
probably subject to be added to the list of things of "people may edit these directly in the .osu" which is part of the general part of general rc... i guess
Topic Starter
pishifat

changelog wrote:

clarified usage of time signatures unsupported by the editor in the "Uninherited timing points must be used to accurately map the song's time signatures." rule

draft wrote:

For time signatures unsupported in the editor, metronome resets or editing of the .osu file are acceptable.
i think we already got that
TheKingHenry

pishifat wrote:

For time signatures unsupported in the editor, metronome resets or editing of the .osu file are acceptable.
I wonder when we will get the advanced time signature settings lol.

pishifat wrote:

There must not be extra uninherited timing points in any difficulty.
Metronome resets as in time signatures will basically lead to this, since there shouldn't be any real need for them. And I don't think "just edit the file" is that good of an answer to a problem of lacking musically fundamental options in the editor.

pishifat wrote:

These can cause timing to shift due to millisecond rounding errors.
Uninherited point spam to achieve time signatures also causes this, which will in single bpm songs with like, say, 13/4 time signature also violate this:

pishifat wrote:

Maps with Single-BPM timing must be perfectly timed.

pishifat wrote:

Single-BPM Timing: Timing which only requires one BPM.
Variable-BPM Timing: Timing which changes BPM irregularly due to a song’s fluctuations.
Why is there no mention of Multiple-BPM Timing? It's not really part of variable timing if each section with different BPM is stable in the same way single BPM timing is. Like for example:

Multiple-BPM Timing: Timing which contains multiple intentionally different BPM. If every section with different BPM is stable, it is to be treated the same way as Single-BPM Timing and thus timed perfectly. If Multiple-BPM timing contain fluctuations in the same fashion as Variable-BPM Timing, it is to be treated as such.

Or smth. I don't care about the wording, but I think this term should be added to the glossary since neither one of the current two really contain the idea of Multiple-BPM Timing.
anna apple
-An inherited point does not need to be snapped to the timeline currently. Is it worth mentioning this in this document?
Topic Starter
pishifat
changelog:
added multi-bpm to the glossary and inserted it into the "single-bpm maps must be perfectly timed" rule (as per kinghenry's suggestion)


the other stuff:
kinghenry's other concerns have to do with how poorly time signature changes are handled in the editor, which the ranking criteria has no control over. when those eventually change, the ranking criteria will change accordingly too!

bor wrote:

-An inherited point does not need to be snapped to the timeline currently. Is it worth mentioning this in this document?
there's no reason to restrict inherited point snapping, so no


considering the only change this round was minor, we can probably go ahead and bubble this
Endaris
Assuming I have a variable bpm song and a spot that suggests a multi-repeatslider (say 4 repeats).
2 of the repeats are slightly off by say +10ms.
Could it be considered acceptable to use a modified hitsound that has more delay for these 2 repeats so the hitsounds are on time while the repeats are slightly off?
Monstrata
The repeats would be unsnapped then since slider-length is absolute across repeats, so you should use a different rhythm instead xP.
Endaris
Late answer but: I was assuming a short snapping of 1/4 to 1/12, say on soli parts where it wouldn't be feasible to use a different rhythm due to the difficulty of prediction (meter changes/quintols/septols/...) and also due to a possibly unwarranted amount of tapping that doesn't complement the song in terms of emphasis.
So a spot where the only other thing you can imagine to map being a break.
Monstrata
Probably better if you gave an example. Right now though, using purposefully delayed hitsounding sounds counterintuitive since it doesn't actually give players accurate feedback.
Myxo

Endaris wrote:

Assuming I have a variable bpm song and a spot that suggests a multi-repeatslider (say 4 repeats).
2 of the repeats are slightly off by say +10ms.
Could it be considered acceptable to use a modified hitsound that has more delay for these 2 repeats so the hitsounds are on time while the repeats are slightly off?
You just leave the hitsounds as they are. If it doesn't sound off ingame, it's fine. If it sounds off ingame, you map a different rhythm.
Okoratu
This draft has been amended to the General section of the Ranking Criteria and can be found here!

As this whole thing involves a lot of changes, the usual 6 month ruling applies:
  1. maps that are submitted from this post onward will be handled according to the new criteria.
  2. maps that were already submitted may be handled according to the old criteria for the coming 6 months.


Once 6 months have passed, all maps will have to comply with this ruleset regardless of submission status!


I'm actually not 100% sure why you would choose to hold yourself to the old criteria for this section of the Ranking Criteria because it seems to allow less in its previous state, but half a year to transition seems fair - so transition, ho!
Topic Starter
pishifat
thread moved because finalized amendment
Please sign in to reply.

New reply