Usage of sliderator sliders are in an extremely gray area right now, with maps being ranked containing these objects, like Sorochinskaya Yarmarka by Mazzerin and Transhumanist by hifu. We've seen these sliders in many maps before but ranking it has always been a controversial topic, especially within Beatmap Nominators and more prominent modders + mappers. The best way to resolve these confusions is to clarify usage of said sliders in the Ranking Criteria, as this would clear it up completely.

Usage
As we've seen in the ranked section, and as I mentioned before, more beatmaps have entered qualified and gone through to ranked with the use of these velocity-changing sliders. The nominators for these maps have gone through extensive check to make sure that these are OK to go into qualification; see this note by Mokobe. These sliders are used for creativity and visual purposes, and most of the time do not affect gameplay. In the case of Transhumanist, these velocity changes do not have slider ticks, which enable a bigger visual effect and less of an addition to gameplay "difficulty". In Sorochinskaya Yarmarka, though, sliderticks are present on some of these velocity sliders; but the difference is that this map gives a clear indication that the velocity is changing, and Transhumanist gives less of a warning. This should definitely be clarified, as straight up allowing it might cause some issues related to indicators on how to know if there is a slider that has deceiving velocity.

Solution / Discussion
Obviously, the topic of either disallowing or allowing these objects in a map is very conversational (as I stated), and I believe further discussion should be taken as to what should and shouldn't be accepted in a beatmap, which is why I have made this post. I have made a draft on what the rule(s) would be stated as, and I will put them below.

Draft
Allowance: Sliders that use anchors to manipulate the slider's velocity in a way that can not be performed with inherited points are allowed. External tools such as Mapping Tools may be used to create these objects. (This would be more like a clause instead of a rule.)

Allowance with exception: Sliders that use anchors to manipulate the slider's velocity in a way that can not be performed with inherited points are allowed, as long as no slider ticks are present, or if there is a clear indication of the velocity being changed. External tools such as Mapping Tools may be used to create these objects. (Same as above, this would be more like a clause instead of a rule.)

Disallowance: Sliders must not use anchors to manipulate the slider's velocity in a way that can not be performed with inherited points.

Would really appreciate some suggestions for rephrasing of my words as I'm not the greatest when it comes to this

+1

+1

Yep this situation should definitely have a clear line drwan in somewhere.

I don't personally like the idea of using external program to create something that isn't practical to do in the editor yourself. Even if it's done well and predictably i think it goes against the mechanics and intentions of what you should be able to do in the editor. So for now at least. So based on that i think time isn't there yet until we have the offical support to do those things.

(Falls to me with pretty much the same category as supporting 16:9 resolution. It'd make sense but there isn't offical support for it so ranking criteria or the editor don't allow it.)

+1

this is nice but didnt peppy say smth about not doing this because itd mess with osu lazer? ill find it somewhere or my minds dumb, saw the sliders and they seem playable and cool af

bluirre wrote:

+1

this is nice but didnt peppy say smth about not doing this because itd mess with osu lazer? ill find it somewhere or my minds dumb, saw the sliders and they seem playable and cool af

Hmm maybe, not sure how it would though, maybe something to do with the new editor

atlas- wrote:

bluirre wrote:

+1

this is nice but didnt peppy say smth about not doing this because itd mess with osu lazer? ill find it somewhere or my minds dumb, saw the sliders and they seem playable and cool af

Hmm maybe, not sure how it would though, maybe something to do with the new editor

they said smth about the spam of bezier points could be laggy I can find the exact Twitter post somewhere if u want

accel sliders being added to the guideline section of the rc (instead of rules) would be the best solution instead of just taking them off the rule list completely (so in general its advised against, but when used well it can be ranked)

as imo right now i completely understand why this was ruled against in the first place, as without proper structure around accel sliders there can be really bad results, as this is a specific technique that *cant* be read by the player at all, so it 100% *requires* proper setup and map wide planning to be readable through cosnsitent patterning and usage (or just really slow singular usages)

great examples of using this technique well and why it shouldnt be 100% banned are maps like beatmapsets/1238827#osu/2575710 (entire kiai sections) and beatmapsets/1546763#osu/3161211 (specifically the object at 04:02:233 (1) - being an amazing use of this)

just wanted to add this all on as while i do want this technique to be rankable it does need some restrictions (in the form of it being a guideline in the rc instead of just a rule) so that usage of it can be more easily monitored in qualified maps

DeviousPanda wrote:

accel sliders being added to the guideline section of the rc (instead of rules) would be the best solution instead of just taking them off the rule list completely (so in general its advised against, but when used well it can be ranked)

as imo right now i completely understand why this was ruled against in the first place, as without proper structure around accel sliders there can be really bad results, as this is a specific technique that *cant* be read by the player at all, so it 100% *requires* proper setup and map wide planning to be readable through cosnsitent patterning and usage (or just really slow singular usages)

great examples of using this technique well and why it shouldnt be 100% banned are maps like beatmapsets/1238827#osu/2575710 (entire kiai sections) and beatmapsets/1546763#osu/3161211 (specifically the object at 04:02:233 (1) - being an amazing use of this)

just wanted to add this all on as while i do want this technique to be rankable it does need some restrictions (in the form of it being a guideline in the rc instead of just a rule) so that usage of it can be more easily monitored in qualified maps

Yeah, I agree with this. I think using it in entire bulked section is WAY too overkill but using it once every however-long sounds better to me though

did i +1 this?

anw this is so based

If you're going to talk about confusion caused by the RC and want things to be clarified, it would be good to mention the relevant RC rules and point out what makes their interpretation supposedly unclear.

All that's being said is "stuff is getting ranked" by mentioning 2 examples of which one is allowed (Mazzerin's) by the current ruling and the other (hifu's) is not. Unrankables getting ranked unfortunately happens though, so that doesn't actually mean a whole lot.

My issue issue with these types of sliders is that they can be made to work .. but they don't work by themselves. Essentially you're going from a game where all information can be visually derived => a game where some information is uncertain until you've experienced it.

That is a massive difference considering just how fast this information passes by you. Can turn maps into legitimate guesswork

I wish there was some level of gameplay where players could be somehow clued into these things by sheer gameplay experience, but as far as I know there is no such thing.

The whole slidertick thing is kinda fishy to me because essentially it's saying "what the slider actually does doesn't matter as long as there are no sliderticks" which comes across as the opposite of using things with intent.

So if this clarification is necessary, then I'm absolutely for the direction of "disallowance" because that's what the current rule already does anyway.

Also why the fuck are people +1'ing a post that offers multiple solutions and asks for discussion? Do you actually read?

yea id prefer discussion over "+1 this is good"
i apologise for my tricky wording but also im not entirely sure where this is already stated / covered in the rc so would appreciate if u could inform me

Ranking Criteria wrote:

Every slider must have a clear and visible path of movement to follow from start to end. Sliders that overlap themselves without straightforward slider borders and sliders whose individual sections are unreadable cannot be used. A slider's end position must be clear under the assumption that a player has a skin which makes slider end circles fully transparent.

is the relevant rule

ahh i see
yeah that covers it but still kinda vague especially cuz its such a recognized "concept" ig

I think contextualized sliderator is pretty cool - but as yaspo mentioned it’s pretty iffy as without the proper context the sliders can end up being really really difficult to play/read. Although I don’t think that’s a terrible thing - as there are a plethora of maps that are “unsightreadable”, so kind of on the fence about this.

Might be better to not explicitly disallow sliderator from rc and just let bns use personal judgement on whether or not the usage or sliderator in maps is justified?

Though the outcome of this doesn’t matter too heavily IMO - sliderator has very few practical or justifiable uses.

i wholeheartedly believe discretion should be left to the nominators for maps which use sliderator / related "invisible" techniques rather than disallowing them explicitly

yeah i agree with waf and apollo, i think there should be a less vague writing in the RC about it though, possibly a guideline? I'm not entirely sure how this would be worded though

gonna bump for visibility

Not sure if anyone else had concerns to address

gonna bump this for money
bump commission

If we're going about adding a guideline for this, I think the best wording is:
Sliders that use anchors to manipulate the slider's velocity may be used, if the change in velocity is discernible and not excessive. External tools such as Mapping Tools can be used to create such objects.

Guidelines are already implied that the Nominators can decide if the usage is too extreme etc, so I think there's no reason to add that on.

i keep seeing ppl to want to bump this thread, which i find kinda awkward because
this thread was about clarifying the ruling around these slidertypes in the ignorance that there already was a relevant rule (which can still get said clarification, just nobody else is voicing the need for it so ??)

apparently now it's about bending the relevant rule out of shape to be more allowing, which is an entirely different topic. yay

anyways - that guideline suggestion isn't great because "slider velocity" is a real term that is already being used. Incredibly confusing. I'd suggest alternative wording but I'm not sure of what the goal is at this point

as for "should be allowed within BN's discretion", to some degree I'd agree
.. but then I remind myself that BN discretion can simply come down to "it fits the song" (see High Powered for 1 example). This is not sufficient because these sliders require a certain context to work; they need to be designed around.