Hallo!

With a bunch of Ranking Criteria drafts from the UBKRC already amended or even already active Ranking Criteria for quite some time I think it's time for this sort of thread.

Use this thread to debate the most recent additions to the Ranking Criteria (that is all already amended proposals, excluding the rules and guidelines that existed before the UBKRC was a thing!) and whether anything needs to change in your opinion or doesn't work as originally intended.

We will bring up all the issues found in here in the respective sections of the UBKRC in order to reach a solution if necessary.

Throw stuff here if you don't think it's working as intended, because the process of contacting a random member of any UBKRC in private is arguably very rare and you cannot be sure if it even ends up discussed anywhere else so going forward we'll use this thread as a public platform for anything of that nature.

Discuss!
Or dont!
I mean can't force anyone to voice their opinion if they don't want.

Double post for sidenotes: We are aware of https://osu.ppy.sh/community/forums/topics/634624 and will include something about that in the next update for https://osu.ppy.sh/community/forums/topics/602580 (which we're actually working on)

Is there a changelog for easy access for people (like me, unfortunately) who haven't kept up with the discussion? If not I suppose I can just figure it out lol

regarding the timing rule:
An object which is wrongly snapped due to...

seems unnecessary to have two separate dot points covering basically the same thing, when the description for each is identical. probably can be condensed down to a single point for simplicity

@Hobbes: best i can do is the initial commit on https://github.com/ppy/osu-wiki/pull/704/commits/a4390ab7b70dffa57ecf70a38f9f4386c38e17aa

provided you know how to read this you can pretty much go through the pr to see what's changed recently

@Pentori: i kind of agree, but i also think there was a distinct reason to split this off into two guidelines @pishi

Just something that has bothered me for a while as I have seen it used to good effect in unranked maps for some time now:

When perfectly overlapping two slider bodies, the first slider must be fully faded out before the second slider is fully faded in.

Seems like this should be more of a guideline than anything. I know in most circumstances perfectly overlapping sliders without proper fade time can cause ambiguity but making it a full fledged rule with 0 leeway seems a bit overly restrictive. The intent of this rule is seemingly about preventing unreadable sliders but the precise wording also rules out many cases of readable sliders as well. I would be surprised if there weren't at least 2 BN in the BNG with enough play experience on gimmick maps to be able identify and push forward maps where perfect slider stacks are implemented properly.

Edit: Forgive me for not clicking on the link earlier, I've been out of touch the past few months due to RL obligations and don't spend as much time reading stuff before posting these days. Seems this is already being looked at. xd

Regarding the rules in the standard specific criteria, regarding sliderbodies:

Slider body color cannot be too similar to slider border color. If both of these settings are too similar to each other, then the slider border element loses its point as a visual border for the slider. Slider body color can be selected by adding SliderTrackOverride: <RGB Value> under [Colours] in a .osu file.

Is it really necessary to have this as a rule? Even if the body and border blend together, sliders are still perfectly readable due to body shading and transparency. The only time this isn't the case is when both body/border are so dark they blend in with a heavily dimmed background.
I think it should be a guideline, or the rule changed to where this only applies when border or body falls below a certain luminosity, similar to current restrictions on combo colors.

an actual problem
versus

not a problem at all??
is the latter really considered a problem? It seems like an unnecessary restriction of skinning freedom. I think only cases like the first image is the real issue that should be worried about.

Both slider border and body colors must be manually set or not set. Setting only one may conflict with a user's custom skin choices.

The logic for this being to prevent the border/body conflicting between user/beatmap skins and blending in.

But.. I had to go out of my way to intentionally make the colors in the above slider blend together. Even slightly different colors are still distinguishable and cause no problems in slider reading. The chances of a user and beatmap skin conflicting to where this would happen are incredibly low, which is why I think this rule is excessive.

On top of that, it is rather heavy handed, as it forces the major function of beatmap skinning (besides combobursts) to have either a set body color or forced default skin.

Why forcing the set body color is bad:

1. It can reduce the presence of combo colors. (which itself can cause reading difficulty for someone not used to it.)
2. It can restrict the choice of combo colors in order to avoid colors clashing.

Why forcing set default skin is bad:

1. It will make more elements than intended take away from the player's skin.
2. It will encourage the player to disable what may have been a minimal beatmap skin. They may have been fine with skinned hitcircles, but not the pippi comboburst.

At the least, I think the following exception should be added:

If the sliderborder is set to pure white, RGB: 255,255,255 , it is not required to set a sliderbody color. This is because a white border cannot blend in with the body in any case.

This would allow a third more lenient option than the above two for those who wish to skin hitcircles in their mapset.


tl;dr i think the rules in the std rc about slidertrackoverride and sliderborder are heavy handed and unnecessary. please either revise as a guideline, or a rule for dark borders specifically, or add an exception for white sliderborders as it's impossible for them to blend with the body.

I believe it is very important for the ranking criteria to address the way in which songs with time signatures of x/8 ought to be timed, as currently it is only suggested that the timing be 'accurate' which is very subjective and can lead to a great amount of debate when the song has an odd number for the top of the time signature, as it cannot be reduced, which is a problem in its own right (i.e.: 7/8 -> 3.5/4)

The best way to set a precedent for song's with time signatures of this matter is to simply require that an uninherited timing point is placed at the first beat of every measure with the correct bpm and the time signature represented with the correct number on top. For example: 7/8 at 100bpm would be timed as 7/4 at 100bpm with an uninherited point at the start of each measure (which would be half of a 7/4 measure) so that the correct time signature can at the very least be ascertained given the timing data within the map and the metronome resets as it ought to, to represent the music correctly.

The alternative is to double the bpm of the music and time as 7/4, though i strongly disagree with this suggested implementation as it presents multiple problems. Doubling the bpm makes the song read an incorrect bpm, and if the song has other parts with standard time signatures, you will have both x bpm and x*2 bpm which will mess with SV and again, read incorrectly in the map info, as the map is not in any way x*2 bpm. For example, if a song were to alternate between standard 4/4 at 110bpm and 7/8 at 100bpm, requiring that the 7/8 section is timed as 7/4 at 200bpm does not truly represent the music and only further convolutes the process as well as requiring the mapper to constantly reset the SV for each section. This would save on the number of red-lines in the map, but at the cost of inaccuracy, there is no benefit in doing so other than a desire to do less work.

Another more minor topic that i would like to address is the simplification of compound time signatures. Often times in music, 7/8 is played in groupings of 4 beats and 3 beats, 10/4 as 2 groupings of 3 and 2 of 2, (etc..) which in some cases is urged to be timed instead as alternating 4/4 and 3/4 or alternating 6/4 and 4/4, respectively. Reducing these compound time signatures to their groupings does not result in a higher degree of accuracy and 99 times out of 100 in music, the artist would represent this as 7/8 or 10/4 in their notation. It is too often that I see compound time signatures urged to be reduced when it achieves nothing and merely represents the music in a parallel but more convoluted way. Simply including an addendum that addresses this with a "Compound time signatures are not required to be reduced to more common expressions" would address and absolve this problem.

If anyone should desire a deeper explanation or have any questions I'd be happy to help. I strongly urge the team to consider addressing either or both points formally in the ranking criteria as I have seen it become a point of contention between mappers and the BN/QAT team as there is no precedence or level of understanding as to how to treat these cases.

@chainpullz you're forgiven xD

@Noffy: The argument about white border colour as an exception is very reasonable and seems like a good change, the second half of it we still argue that a sliderborder uses it's purpose of being a sliderborder if you can't see it being like an actual border.

You argue with skinning freedom and that this ~isn't actually a problem~, black borders are banned to begin with if i recall correctly.

I still think a border should be a border so either you have a setting that physically cannot conflict (which would be white) or you give mappers a means of not having them conflict

@dsco:
While you are correct in how these sort of timings should usually be handled, neither pishifat nor Okorin nor me were able to remember any instances of them being handled incorrectly. Both /8-signatures and compound signatures are mapped so rarely in osu! that it seems unnecessary to mention anything about them in the RC. If you stumble upon specific cases of them being handled incorrectly, you are of course encouraged to adress those in their respective mapthread/-panel (and notify me about them too bc I'm curious about how often you seem to stumble upon those), but it's not the RC's purpose to cover everything that could possibly be done incorrectly in osu! ever.
To me, those explanations of somewhat unusal timings seem like something that would belong in a guide - I've considered writing some timing-guides for a long time but haven't found the motivation for it yet, feel free to outdo me on that!

Okorin wrote:

@Noffy: The argument about white border colour as an exception is very reasonable and seems like a good change, the second half of it we still argue that a sliderborder uses it's purpose of being a sliderborder if you can't see it being like an actual border.

You argue with skinning freedom and that this ~isn't actually a problem~, black borders are banned to begin with if i recall correctly.

I still think a border should be a border so either you have a setting that physically cannot conflict (which would be white) or you give mappers a means of not having them conflict

Leave it to me to somehow totally miss something despite multiple reviews of all related content <_<

But yes, please seriously consider adding in the white border alternative! Thanks!!

Bonsai wrote:

@dsco:
While you are correct in how these sort of timings should usually be handled, neither pishifat nor Okorin nor me were able to remember any instances of them being handled incorrectly. Both /8-signatures and compound signatures are mapped so rarely in osu! that it seems unnecessary to mention anything about them in the RC. If you stumble upon specific cases of them being handled incorrectly, you are of course encouraged to adress those in their respective mapthread/-panel (and notify me about them too bc I'm curious about how often you seem to stumble upon those), but it's not the RC's purpose to cover everything that could possibly be done incorrectly in osu! ever.
To me, those explanations of somewhat unusal timings seem like something that would belong in a guide - I've considered writing some timing-guides for a long time but haven't found the motivation for it yet, feel free to outdo me on that!

it's not so much a matter of it being done incorrectly but it being an unnecessary obstacle in ranking a map should this arise. for example, in this map: https://osu.ppy.sh/b/1185249 everything is quantized and represents the music accurately, but it is currently at a halt for progression through the ranking process because its timing accuracy has been called into question, because there is no standardization for how this ought to be handled. just because it is a problem that arises rarely or affects a minority of people doesn't mean it should not be addressed. as well, on my own map (https://osu.ppy.sh/s/600881), i had to reduce a song with a 13/4 section to groupings of 3/4 and 4/4 because it was thought to be more accurate (despite 13/4 being present in other sections of the song anyways).

there are also maps with absolute messes of timing in the ranked section such as all ranked versions of Jack-the-Ripper, BEELZEBOSS (parts of this map call into question whether truncated measures require having an accurate time signature, which i've both been told is required and unnecessary), paraoka's L9 is timed at 2x bpm for 6/8 and 7/8 in irreversible's (though unranked) set, mazzerin's The Obsidian Crown Unbound has a section timed at 146 bpm instead of 219bpm (the entire first half of the map is 219bpm 3/4, 146bpm is 219/1.5, not sure in any capacity why this was done but it is akin to halving/doubling the bpm for an x/8 section), those who from the heaven's came has a 15/8 section as 7/4 in the editor (and the metronome resets before the next red line begins), apparition has an entire 20 second section that is timed 1 beat off of where the downbeats are 80% of the way through the song as well as sections that are arbitrarily half the bpm because they are a more relaxed pace with less dense phrasing, cosmic cortex twice has a full minute of map that is a half beat off because there is no metronome reset after a 7/8 measure right before the guitar solo 24% and 78% in, fast paced society has an alternating 11/4 and 12/4 section timed as 4/4 (11/4+12/4 doesnt even resync with 4/4 when it repeats), save me is a song written entirely in 6/8 and 4/4 but timed as 6/4 (should you should reduce to 3/4 but could do 6/4 with metronome resets every bar), while simultaneously altale is 6/8 timed reduced to 3/4, tetrastructrual minds has alternating 6/4 and 4/4 that is quite clearly just 5/4, tales of the destinies has 11/8 timed as truncated 6/4, 15/8 as 5/4... and there's undoubtedly more but this is all i could come up with in an hour.

as it currently stands there are several different approaches for handling these cases and all can/have been met with pushback from those responsible in the ranking process. some maps are timed incorrectly and meet no qualms and others are called into question because there is no standard at all for how these maps are treated. it seems some members of the BN/QAT team believe that if the timing points can allow circles to be placed in time with the music then its correctly timed, but this is an awful point of view to hold as you could time simple music in extremely roundabout, terribly complex and absurd ways and be able to place circles in sync with the music. it is way too grey of an area to simply rely on BN/QAT's best judgment when it seems that clearly there are too few people capable of passing judgment on difficult and complex timing in the ranking staff.

it is a unnecessary hurdle that would be easy for the RC to address and i very strongly believe it ought to be standardized so that people can tell given the RC how to handle x/8 (or x/16, etc) time signatures in the game, rather than have to pester one of the very few people knowledgeable on the subject and rely on the ranking team to give their map a pass so long as the objects are in sync with the music.

Isn't mapping 6/8 in 2/4 also an option (though this requires notepad editing)? Typically 6/8 is counted in 2 with mental subdivision anyways. BPM is kind of just a superficial number implicated by the combination of time signature and the tempo marking (which are usually just rough guidelines in actual music anyways) so I think making sure the downbeats land on big white ticks is the more important part.

Just a note on sticking an inherited section down frequently to reset the measure - you will probably incur non-negligible drift from doing this as the place you are snapping to each time is rounded to the nearest millisecond. There was a doormat map I looked at once upon a time where the timing drifted like a whole 5ms simply from changing time signature a dozen times throughout the map.

i feel like i should comment on the issue of time signatures as well since i like mapping songs with them and have gotten quite a few headaches due to the undefinedness of their proper implementation.

i agree with dsco's suggestion, it's more or less a cleaner variant of what i typically do and i consider it the most accurate implementation allowed by the system. it would also be a fairly minor update to the current rule wording with something like:

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 uninherited timing point must be added on the next downbeat to reset the time signature. For time signatures unsupported in the editor, the numerator must be set to the correct value using .osu editing if necessary, while using metronome resets to accurately map the downbeats if the denominator is greater than 4.

as for the concern of drift due to rounding errors, this is actually fairly easy to prevent by adding the metronome resets starting from the end of the song or even just segmenting the song from the end before adding resets to each segment.

chainpullz wrote:

Isn't mapping 6/8 in 2/4 also an option (though this requires notepad editing)? Typically 6/8 is counted in 2 with mental subdivision anyways. BPM is kind of just a superficial number implicated by the combination of time signature and the tempo marking (which are usually just rough guidelines in actual music anyways) so I think making sure the downbeats land on big white ticks is the more important part.

Just a note on sticking an inherited section down frequently to reset the measure - you will probably incur non-negligible drift from doing this as the place you are snapping to each time is rounded to the nearest millisecond. There was a doormat map I looked at once upon a time where the timing drifted like a whole 5ms simply from changing time signature a dozen times throughout the map.

6/8 is most commonly divided into 2s, with 3 beats per measure *in modern music (see altale, save me, others..). perhaps you are thinking of 12/8, where there are 4 beats of 3 most commonly.

5ms drift is negligible anyways and according to BN/QAT that i've talked to, as long as the timing points are within 5-10ms of accuracy, the timing is ok. drift can be fixed anyways, but ya.

Oh, didn't know that about modern music. In classical music 6/8 would typically be conducted in 2 (tri-ple-let tri-ple-let). 12/8 wasn't very common in anything I encountered as a musician. It makes sense that it would depend on the genre though (waltz are often 3/4 conducted in one despite slower tempo).

timing ubkrc guys are working on fixes to help regulate these weird time signatures more clearly

just letting you guys know so you can temporarily avoid headaches from this discussion lol

A difficulty's name must indicate its level of difficulty, with the exception of the hardest level of difficulty in a set. The mapset's hardest difficulty may use an appropriate custom difficulty name, unrelated to a username. Mapsets may also use a complete set of custom difficulty names that clearly indicate their level of difficulty to the player. Marathon maps with a single difficulty may use free naming.

What if I rename myself to "Extra" or "Insane"

Jokes aside, I was happening to be browsing through some beatmap threads and i bumped into these ones: t/609114/start=60, t/548782/start=0, p/5770488

tldr; diff name is related to the user, but it's also related to the map itself, so should it be allowed or not?

Maybe a bit more clarification in the rule would be nice, cause it is a rule, not a guideline.

Okoratu wrote:

@Noffy: The argument about white border colour as an exception is very reasonable and seems like a good change, the second half of it we still argue that a sliderborder uses it's purpose of being a sliderborder if you can't see it being like an actual border.

Ok follow-up time since it's been 4 months and no sign of any change. (exception for white sliderborders when?)
Ok, so how does forcing a visible border benefit the player? How would this

be deterimental to reading on a beatmapset?

Who does having a forced visual "border" benefit? How does this improve over not having such a rule in the past? Beatmap skinning is unpopular already, I do not see why it is further discouraged by the addition of an arbitrary rule like such that places further restrictions on skinning the hitcircle set for no clear beneficial reason.

Has the lack of such a rule in the past ever troubled anyone? I think the fact that the minority of skinned beatmaps made use of trackoverride speaks for its unpopularity..


Consider this
https://osu.ppy.sh/s/308633 this would be unrankable now! does that really seem like something that would be deterimental to players?
https://osu.ppy.sh/s/206887 same goes for this! simply setting the border and only the border was simple and effective. have there been any actual cases where a lack of visual border, as stated to be a risk, has actually impaired readability, has actually been deterimental to anyone playing either of these maps? Slider shading functions more to make weird interlapping sliders readable, borders aren't even totally required to be visible on a slider's shape thanks to that. Why force it for skinning?

Ok, for example, for any RGB color, let's have a range of a value of 10 up/down for each R,G,B value
so for example,

240,230,210 as a border and 250,210,230 as a track would be considered matching colors that would make the border less visible as a border.
The chance that a player's track color and a beatmap's border color would match is ~1/2000. That's a .05% chance. So you're going to restrict 100% of beatmaps that want to have skinned hitcircles, for the sake of that .05% chance player. Take into consideration that a threshold of 10 for each r,g,b value is actually extremely wide. the range of colors that would actually cause matching is lower.
This is not even taking into consideration the fact that a significant majority of user skins, if they make use of the slider track override, will make use of dark colors. So these chances of beatmap/user skin having matching colors is even less likely when the slider border is a bright color.
And even if someone is that extremely low chance, they could.. simply disable the skin. It's not like offscreen objects where a player would have no power to improve their experience...


It's been a year and still no function has been made to force combo-colour-based slider track colors as was promised in the thread when this rule was added. Will it ever happen? I doubt it.

sincerely,
frustrated skinner that has only made a two beatmap skin things since the addition of this rule, because she finds it excessive, unnecessary, and dumb, and specifically is discouraged from skinning due to its existence, noffy t. coffee

tl;dr The chances of a beatmap skin with only a set sliderborder and not slidertrackoverride actually causing blending of the two is extraordinarily low. The rule doesn't appear to benefit anything or anybody. What actual benefit does it bring. Make skinning great again.


Actually, to be honest, why is setting a slider border forced if you skin the hitcircle set anyways? There's no rule forcing you to skin the hitcircle set if you have a sliderborder set. It's extremely weird this works in only one direction..
hmm..

Minor thing in ctb overdose guidelines:
"Should" suggests that it may be allowable, changing it to "must" would make it more obvious that edge hyperdashes break the general rules.

Noffy wrote:

tl;dr The chances of a beatmap skin with only a set sliderborder and not slidertrackoverride actually causing blending of the two is extraordinarily low. The rule doesn't appear to benefit anything or anybody. What actual benefit does it bring. Make skinning great again

this^
the rule is extremely pointless since using a custom sliderborder without adding a custom slidertrackoverride makes for a very restrictive type of skinning and as Noffy said, the possibility of the sliderborder conflicting with the user skin slidertrackoverride is extremely low

Noffy wrote:

Actually, to be honest, why is setting a slider border forced if you skin the hitcircle set anyways? There's no rule forcing you to skin the hitcircle set if you have a sliderborder set. It's extremely weird this works in only one direction..
hmm..

i suppose the whole point of it is to avoid conflicts between custom and mapset skins but to be honest, it's really incoherent and if the rc guys were aiming to make it consistent it would basically kill any intend to set a custom slider border/trackoverride.


to end with, i'm just gonna say that i find the current skinning rules too restrictive, currently, you can't have a decently skinned set that uses the way the default skin works with combo colors. by using any hitcircle or slider element, you're forced to add a sliderborder, and by setting a custom sliderborder, you're forced to get rid of the combo colors on the slidertrack which is really dumb if you ask me

I'm reaching the conclusion that this rule seems unnecessary and should be a feature that is added to osu instead, so:

https://github.com/ppy/osu-wiki/pull/983

Btw @Just Monika if you still care diff names that just so happen to be mapper names are allowed or else we wouldnt be allowed to have Hard or because Hard is a user that maps

Regarding the diff name thing, I think using other modes as a name should be avoided.

Eg This set shows up at one of DreStar's top plays, but the diff is called Rain, so it doesn't look like a very impressive play on his profile since rains are easy, and leads to confusion as to why a rain gave so much pp. Doesn't represent the difficulty

other examples https://osu.ppy.sh/s/543250 https://osu.ppy.sh/s/278283 https://osu.ppy.sh/s/195888 https://osu.ppy.sh/s/69076

Not sure how to enforce it though, since it's quite common to call sets in other modes Easy/Normal/Hard.

RC wrote:

Do not manually edit anything in an .osu file that cannot be changed through the Editor. The only exceptions are .osu-specific storyboards, slider velocity multipliers and skin-related options such as SliderBorder and SliderTrackOverride. If non-standard slider velocity multipliers are used, they must be announced in the beatmap description during the modding process.

This lacks an exception for "UseSkinSprites:" which can be placed under the [General] section to enable use of a player's skin elements in a storyboard. This can be used for effects such as faked hit objects. So despite this being a legitimate feature only accessible by editing the .osu file, using this feature is currently technically going against the rules. Which is silly.

Examples of sets that use this feature:

https://osu.ppy.sh/s/632589 (at the end) (yes i broke the rule by using this feature, i'm a bad example, oh no!!)
https://osu.ppy.sh/s/86983 (at the end) (on difficulties hard and up)
https://osu.ppy.sh/s/12903 (at the end)
https://osu.ppy.sh/s/6037 starting at 00:52:118 - in the Hard and Normal+ difficulties.

I've been concerned about Taiko SR inflation for some time... This is something I always wanted to propose:

I think some action has to be taken regarding flams in Taiko. They are always abused to get pp maps, and they waste the balance of the game, making pp system useless since they become "obligatory to farm" maps.

Is it well known that flams are a prefectly acceptable drum rudiment, and they are also featured in the original TnT, but still, they won't be mapped as 1/8 doubles.
First of all, because in theory, this rudiment consists on interpreting two almost-simultaneous beats, the closest possible... And the second matter is that SR is not so well assigned in Taiko and it's not going to be changed any soon as far as I know.

I a kind of rule should be forced there asking flams to be mapped as 1/16 (unless more than 220 bpm songs), which doesn't make pp inflate any bad and also, they play the same, even intermediate players can play them without any problems... This would also make them respect drum theory better... It is a drum game after all.

I made the experiment on various inflated maps with 1/8 flams: I changed them to 1/16 and the SR decreases the same as if you keep them as single notes deleting the 1/8.

This would be great to be taken on consideration.

given how rc amendments work now, this thread isn't necessary