"iintuitive"
Besides, using an object before an uninherited point is fine, right?
Besides, using an object before an uninherited point is fine, right?
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.Agree with Doyak, maybe a timing point should be specified to uninherited point instead to avoid confusion and about the rule above, how about a case on a map with single bpm but with multiple offset reset, if the actual reset time signature of the music is not on the downbeat, should we stick to reset it on the next downbeat? yet the actual reset probably not on the downbeat (like second or third white line). Maybe it's just me, but the wording on that one a bit confusing orz.
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.Wouldn't this be better if we clarify "an uninherited timing point must be added on the~"? Since a timing point can mean an inherited timing point too, which doesn't work in this case.
Speaking with some QAT's, the general argument for that is "why do they have to be different?" Since the only time where different audio settings actually does anything is for kiai's that occur at the start of the song, or in anacrusis when notes occur before the first timing line (but even then, a timing line can be placed further back too).Doyak wrote:
2. 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?
I was just wondering, that as this is a ruleset, if now that is not a "must-fix" issue, since that alone has been a DQ issue so far. So, I guess that's not a real problem anymore?Monstrata wrote:
Speaking with some QAT's, the general argument for that is "why do they have to be different?" Since the only time where different audio settings actually does anything is for kiai's that occur at the start of the song, or in anacrusis when notes occur before the first timing line (but even then, a timing line can be placed further back too).Doyak wrote:
2. 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?
What about adding uninherited points to make NC mod sound not broken?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.
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.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
Unless I'm understanding you wrong, that falls under this doesn't it?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
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.
technically it doesn't, but the ubkrc will discuss it/try to make it clearerLogic Agent wrote:
.
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.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
392,284,204123,2,0,B|344:303|314:295|314:295|253:349|198:323,1,211.5Changing 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.
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
i think we already got thatdraft 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:
For time signatures unsupported in the editor, metronome resets or editing of the .osu file are acceptable.
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:
There must not be extra uninherited timing points in any difficulty.
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:
These can cause timing to shift due to millisecond rounding errors.
pishifat wrote:
Maps with Single-BPM timing must be perfectly timed.
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: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.
there's no reason to restrict inherited point snapping, so nobor wrote:
-An inherited point does not need to be snapped to the timeline currently. Is it worth mentioning this in this document?
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.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?