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
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.
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.
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.
Leave it to me to somehow totally miss something despite multiple reviews of all related content <_<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
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!
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.
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.
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"
Ok follow-up time since it's been 4 months and no sign of any change. (exception for white sliderborders when?)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.
this^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
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.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..
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.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.