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

[Rule Clarification] Stacked points with different volume

posted
Total Posts
19
MillhioreF
Pro Tester
5,004 posts
Joined July 2011
Topic Starter
MillhioreF
For the past few months, it's been to the best of my knowledge that a red point and a green point on the same tick having different volumes is utterly unrankable, because it supposedly creates undefined behavior.



I'm pretty sure this is true for stacked kiai/non-kiai sections, since that might create a zero-length kiai fountain, mess with scoring in Taiko, etc. But does it actually even matter for volume or samplesets? We have at least one ranked map in the past that has differently-stacked volume sections and it works just fine without anyone ever having reported a problem.

I just disqualified Monstrata's recent map for having this issue, except it turns out that it actually serves a purpose: the first timing section of a map will affect all notes that come before it, and in this case a spinner was put before the first timing section to be affected by the red point's sample/volume, and then immediately switch over to the green point's settings afterwards. This is a very strange use (and feels kinda buggy to me) but it seems to work correctly in play without causing undefined behavior.

Different BN and QATs seem to lean in different directions on this, so I'd like to have this new, unwritten rule either set in stone somewhere or rejected entirely, since it's gotten a bit out of hand and nobody seems to agree.
Sonnyc
7,761 posts
Joined June 2008
Sonnyc
Seems pretty related to t/402948
MillhioreF
Pro Tester
5,004 posts
Joined July 2011
Topic Starter
MillhioreF
The OP of that thread was for a different issue, but later posts are very relevant to this one, yes. Might be worth a merge.
Monstrata
Elite Mapper: Aspirant
4,642 posts
Joined May 2013
Monstrata
We should assume that these stacked red and green lines are functioning as intended unless "undefined behavior" is found. Since no one bothered to try testing whether stacked red/green lines with different settings actually caused "undefined behavior" I tested them on my map. And I found nothing wrong. We should not be saying "stacked red and green lines can caused undefined behavior" we should actually determine if they can. Part of the modding process is testing, and finding errors on a map before pushing it forward.

This "issue" isn't even mentioned in the ranking criteria. Only stacked green+green and stacked red+red lines (basically duplicates) are mentioned because those have been proven to cause problems. I would like to hear a staff speak to this issue because it's been the source of quite a few dq's lately. Of course, in many cases this problem can be avoided, but that doesn't mean we can simply choose not to address it.

MillhioreF
Pro Tester
5,004 posts
Joined July 2011
Topic Starter
MillhioreF
I checked the rules again and I think this is the source of all these issues:

Ranking Criteria (under Timing) wrote:

No two uninherited or two inherited timing sections should be placed at the same point. An inherited timing section may be placed on an uninherited timing section (but only to change the slider speed)
This is pretty easy to interpret as "any stacked timing sections that disagree on anything but slider speed are strictly unrankable". So it does become a ranking criteria issue, except it's really stupid and needs to be changed because 1) there's no evidence that it causes undefined behavior and 2) there's actually a valid reason for doing it (changing sample/volume of an anacrusis - notes before the first downbeat - since you can't place a greenpoint before the first redpoint)
Monstrata
Elite Mapper: Aspirant
4,642 posts
Joined May 2013
Monstrata
Anacrusis. Fancy xD.

Well, you also have to consider that red lines by default give the section they are modifying a 1.00x SV multiplier. If the green line modifies the slider-velocity, why can't it modify other things too? As I see it, because the green line is telling you to use say 0.75x slider velocity instead of the default 1.00x that the red line is suggesting, the green line takes precedent over the red line. With that being said, it would be really weird if for some reason the red line's volume or sampleset took precedent over the green line's despite the green line's slider-velocity command taking precedent over the red one. If such a thing occurs, then you can say the stacked red/greens cause undefined behavior.

Something like this is very easy to test out. Just set the red line to default Normal, and import custom hitsounds and have the green line use a custom sampleset. If default can be heard, then there is undefined behavior. This is how I tested it anyways, and I didn't find anything. I also tried setting the volume for the red line to 100% and the green line to 5% to see if volumes overlapped, but nothing.
Sieg
3,981 posts
Joined February 2012
Sieg

MillhioreF wrote:

I just disqualified Monstrata's recent map for having this issue, except it turns out that it actually serves a purpose: the first timing section of a map will affect all notes that come before it, and in this case a spinner was put before the first timing section to be affected by the red point's sample/volume, and then immediately switch over to the green point's settings afterwards. This is a very strange use (and feels kinda buggy to me) but it seems to work correctly in play without causing undefined behavior.
It works the way you described only for the first uninherited timing section.

MillhioreF wrote:

I checked the rules again and I think this is the source of all these issues:

Ranking Criteria (under Timing) wrote:

No two uninherited or two inherited timing sections should be placed at the same point. An inherited timing section may be placed on an uninherited timing section (but only to change the slider speed)
This is pretty easy to interpret as "any stacked timing sections that disagree on anything but slider speed are strictly unrankable". So it does become a ranking criteria issue, except it's really stupid and needs to be changed because 1) there's no evidence that it causes undefined behavior and 2) there's actually a valid reason for doing it (changing sample/volume of an anacrusis - notes before the first downbeat - since you can't place a greenpoint before the first redpoint)
1. Loctav said that there will be a race condition in case of stacked timing sections with different settings, tho I never saw conformation from the devs or such behaviour in a wild.
2. If there really any issues anacrusis can be ignored and first uninherited timing section can be moved, I doubt this will cause any gameplay problems.
MillhioreF
Pro Tester
5,004 posts
Joined July 2011
Topic Starter
MillhioreF

Sieg wrote:

1. Loctav said that there will be a race condition in case of stacked timing sections with different settings, tho I never saw conformation from the devs or such behaviour in a wild.
I really doubt it's a race condition; if anything, it has to do with the order they appear in the .osu file, which means it will at least be consistent every time the map is played, even if the order varies between maps.

Sieg wrote:

2. If there really any issues anacrusis can be ignored and first uninherited timing section can be moved, I doubt this will cause any gameplay problems.
This isn't always possible without adding a couple seconds of silence at the start of the mp3, which seems like bad practice to me.
Sieg
3,981 posts
Joined February 2012
Sieg
It's a guesswork anyway, will be nice if someone from the dev team can clarify how it works.
Garven
osu! Alumni
5,857 posts
Joined January 2010
Garven
You can just determine how many ms one measure is and subtract that from the first offset. There's no need to edit the mp3 at all. There aren't any adverse effects from negative offsets that I am aware of. This way you'll avoid the potential bugginess of having an inherited section before the section it is supposed to inherit from.
Monstrata
Elite Mapper: Aspirant
4,642 posts
Joined May 2013
Monstrata
Hi, Ranking Criteria Council. Any news on this?
Drafura
osu! Alumni
2,620 posts
Joined April 2010
Drafura
If a behavior feels buggy it shouldn't be used as a mapping technique. Let's say in the future an update change this 'buggy' behavior to fix something else, it could make the hitobjects sounds different, or maybe it could even crash the game, we just don't know.

Why would you take this risk when you have clean alternatives ?
softhusky
181 posts
Joined November 2015
softhusky
then why don't you just set the volume on the red point
seems pretty pointless to me

the red point can do anything the green point can do
Monstrata
Elite Mapper: Aspirant
4,642 posts
Joined May 2013
Monstrata

Drafura wrote:

If a behavior feels buggy it shouldn't be used as a mapping technique. Let's say in the future an update change this 'buggy' behavior to fix something else, it could make the hitobjects sounds different, or maybe it could even crash the game, we just don't know.

Why would you take this risk when you have clean alternatives ?
It's never been confirmed to be buggy. Actually i've checked multiple times when testing my map and it's never bugged out once. The rule should be modified to better account for this lack of a problem :P. There are cases where having inconsistent red/green lines is a perfectly valid mapping technique. It's rare, but if maps have gone through despite knowledge of this rule, then we shouldn't consider this a hard rule and have it amended or rewritten as a guideline instead.
Kibbleru
osu! Alumni
5,846 posts
Joined August 2013
Kibbleru

Drafura wrote:

If a behavior feels buggy it shouldn't be used as a mapping technique. Let's say in the future an update change this 'buggy' behavior to fix something else, it could make the hitobjects sounds different, or maybe it could even crash the game, we just don't know.

Why would you take this risk when you have clean alternatives ?
well, the thing is, its NOT buggy, and dqing a map for something that isnt an issue is kinda silly.
MillhioreF
Pro Tester
5,004 posts
Joined July 2011
Topic Starter
MillhioreF
The behavior is strange, and may or may not depend on how the timing points are ordered in the .osu file (haven't tested this extensively), but it's completely stable - if it works, it will always work, and doesn't cause undefined behavior.
Endaris
5,282 posts
Joined June 2010
Endaris

Sieg wrote:

It's a guesswork anyway, will be nice if someone from the dev team can clarify how it works.
would still be the best thing for this thread
Sieg
3,981 posts
Joined February 2012
Sieg

MillhioreF wrote:

The behavior is strange, and may or may not depend on how the timing points are ordered in the .osu file (haven't tested this extensively), but it's completely stable - if it works, it will always work, and doesn't cause undefined behavior.
most likely

well, from what I've heard... atm sorting works as uninherited first in case of stacked timing points and picked timing point for playing hitsound sample is always the last one, so volume level change is not an issue
Myxo
osu! Alumni
3,103 posts
Joined December 2012
Myxo
With the change of how the Ranking Criteria Subforum works from now on, topics like these are obsolete. This topic is already being discussed by the Ranking Criteria Council.
Please sign in to reply.

New reply

0
1 / 19