I believe this may have been discussed somewhere already in which case my bad, but I feel that the gameplay element has received enough momentum to warrant a proper consideration for a change to the ranking criteria

A while ago, OliBomby added a tool dubbed Sliderator for his 3rd party Mapping Tools program, which lets people create sliders that abuse anchors to give sliders changing velocities. While these sliders are a novel idea and very cool for making fancy maps that might be seen in Aspire or something, I don't think it's viable to include these sliders in official ranked content:

1. They create the issue of readability; how do people know how the acceleration of the slider will play? Experienced players would probably be able to adapt and adjust in higher diffs, but I think on diffs below Extra it'd become an issue.
2. It's difficult to determine what sounds or parts in a song would be an appropriate place to put accelerating sliders. I can see this causing a lot of subjective/quality concerns in the future where people try to use the sliders on sounds that others think they don't belong on.
3. Technically you can only create these sliders "perfectly" using 3rd party programs and editing of the .osu file.
4. Might also be a problem if used in catch maps - I have very little experience in that gamemode so don't quote me on this, but seeing as its maps also use sliders in a parallel way to standard, using the accelerating sliders might lead to some unfavourable gameplay?

here's a pretty extreme example for those who haven't seen it: beatmapsets/1118948#osu/2337178 (far from rankable due to 2B, but it demonstrates the accelerating slider concept well in the early parts of the map)

So far the consensus between myself and other BNs has just been "don't rank this since it's weird", but I think it would be preferable to include something in the RC that explicitly restricts these sliders; or if anyone disagrees, then please discuss - I can maybe see some discrete circumstances where they'd be acceptable, but something would need to be agreed upon.

Here's peppy saying it'll break on lazer and shouldn't be ranked.
So even though justifiable situations could exist just like with burai, ranking something that'll break in the upcoming client seems of the table.

Haven't had the chance to actually check it on lazer though, kinda taking peppy's word for it.

As for a rule we could probably copy pasta the burai rule and adjust it a bit, eg

Rule wrote:

Every slider must have a clear travel speed from start to end. Sliders that speed up or slow down without straightforward slider borders and sliders whose individual sections are unreadable cannot be used.

(Using tweets as argumentation, this is the future)

Rule wrote:

Every slider must have a clear travel speed from start to end. Sliders that speed up or slow down without straightforward slider borders and sliders whose individual sections are unreadable cannot be used.

Do indicators via storyboard count?

"without straightforward slider borders" essentially means the slider on its own has to be readable, without additional indicators

I don't believe it's clear. The rule doesn't explicitly say that additional indicators do not count.

why not adding this same option in the client itself then? would make more sense since some people uses this tool and it will not make as much anchors as it does rn.
imo that's readable to some extent (slider at the end of a map w/ decreasing velocity, tech maps which uses the tool to consistently slow down/speed up sliders) but yeah;
i think i'd be okay with those kind of sliders, just not a single, random slider in the map, which would be fkin evil.
just don't abuse it and it should be fine

hi just wanna drop my opinion here

while I think this could be implemented in the RC, I feel like maps like idke's kokoro + satorare would get hurt by things like this. (Take this 04:48:310 - as an example)

The way sliderinator works is spamming an enormous amount nodes, and it spams nearly every single pixels in the editor, which i believe is why peppy doesn't like it (and might break if he in the later date updates how slidernodes work). While kokoro + satorare itself does the job pretty well without spamming every pixel in the editor, and the acceleration speed isnt high enough to render the gameplay frustating.

I would suggest something like decelerating/accelerating is acceptable, as long as it doesnt spam too many nodes and is predictable.

This requires it to be inside the guideline instead of rule though due to the fact that it has a bit of ambiguity.

Thanks for coming to my ted talk


tldr; its ok just make sure u dont spam a fuckton of nodes and make sure the acceleration is predictable (eg by already accelerating since the start of the slider)

Never4Ever wrote:

why not adding this same option in the client itself then? would make more sense since some people uses this tool and it will not make as much anchors as it does rn.
imo that's readable to some extent (slider at the end of a map w/ decreasing velocity, tech maps which uses the tool to consistently slow down/speed up sliders) but yeah;
i think i'd be okay with those kind of sliders, just not a single, random slider in the map, which would be fkin evil.
just don't abuse it and it should be fine

i've suggested this for lazer in the past: https://github.com/ppy/osu/issues/4305
but there's 0 way this is coming in the stable client as it's feature-locked so i'd say just wait for lazer to be a thing instead of allowing an unintended "solution" like this

-Keitaro wrote:

hi just wanna drop my opinion here

while I think this could be implemented in the RC, I feel like maps like idke's kokoro + satorare would get hurt by things like this. (Take this 04:48:310 - as an example)

The way sliderinator works is spamming an enormous amount nodes, and it spams nearly every single pixels in the editor, which i believe is why peppy doesn't like it (and might break if he in the later date updates how slidernodes work). While kokoro + satorare itself does the job pretty well without spamming every pixel in the editor, and the acceleration speed isnt high enough to render the gameplay frustating.

I would suggest something like decelerating/accelerating is acceptable, as long as it doesnt spam too many nodes and is predictable.

This requires it to be inside the guideline instead of rule though due to the fact that it has a bit of ambiguity.

Thanks for coming to my ted talk


tldr; its ok just make sure u dont spam a fuckton of nodes and make sure the acceleration is predictable (eg by already accelerating since the start of the slider)

the problem with this argument is that none of the sliders in this map are actually modifying the speed in the middle of the slider. these sliders are nothing more than an aesthetic way to decrease effective sv, and aren't accelerating/decelerating at all (if they are, it may be unintentional or so minimal that it's not noticeable so I wont count it)

EDIT: @yaspo by "additional indicators" do you mean sliders like this (assume that the slider changes effective sv throughout with farther away nodes or sparser nodes)?

Agree with LASS on idke's satorare, all sliders move at a consistent speed which makes them the effective equivalent of SV changes. Personally felt like the "straightforward sliderborders" thing would make these cases okay, but maybe some better wording could be used.

By additional indicators I'm literally referring to using storyboards as a way to indicate sliderspeedchanges. If the ruling around storyboards is unclear, then that should probably go in the general storyboard rules and not this rule imo. You could use storyboards to circumvent pretty much any visual rule.

From brief lazer testing, Keitaro seems spot on, it's the amount of nodes that causes the issue, making the client crash on Fanzhen's map but it deal fine with idke's. (It's gonna be really sad to see the newest Aspire entries being unusable on lazer lol)
That means technically the rule should be "don't use olibomby's sliderator tool on maps for rank" but that sounds kinda weird. So I'm guessing we're looking for "Don't use an absurd amount of slidernodes. It breaks Lazer".

So, how about this regarding speedchanging sliders:

Rule wrote:

Every slider must have a clear travel speed from start to end. Sliders that speed up or slow down without naturally matching changes in their sliderbody and sliders whose individual sections are unreadable cannot be used.

Where naturally matching would be along the lines of "noticeable thicker slider = slow down" and "noticeably slimmer = speed up"; natural because it's slider behaviour as we know it. I'm guessing the rule should clarify "naturally matching" by itself though.

here's a accelerating slider taken from this ranked map


i pretty much agree with the main post because even if you have a visual clue and is supported by the song in this context, i don't think it would be that predictable by anyone who plays it when it uses such drastic "artificial" sv change.

i can only think on some very specific context where the slider have a really low sv and is very long where using this gimmick may be fine (for example, to represent "glitchy" sounds) but that's pretty much it

there should be a way to define drastic sv changes like these for that which should be not usable at all for the ranked section.

Technically accelerating sliders are already sliders that "overlap themselves without straightforward slider borders". Those invisible overlaps are where the changes in speed come from and also cause all sections of the slider to fall under "sliders whose individual sections are unreadable".

The fact that the sliders overlap themselves is evident based on the node placement and the rotation of the sliderball while traversing the slider. It is traversing the unreadable self-overlapping individual sections and cannot be rankable by definition of the current rule already. Micro-overlaps are still overlaps at the end of the day.

As a result I don't think this needs a rule but rather an additional clarification in the burai slider rule for those people that somehow lack an understanding of what "clear and visible path" means for a slider if anything.

I think reiterating the rule to stress the movement of the sliderball being predictable by the player could work but might come with some unwanted implications in regards to SV changes in general. I have a bit of trouble in coming up with something specific as everything I attempt to write seems redundant as the current ruling clearly outlaws this kind of slider already in my head.

On the notion of the kotoko + satorare example...
In most cases the outline of the slider indicates the placement of the red ticks to a sufficient degree to accurately predict the movement of the sliderball.
Some of the sliders however, most notably the straight ones, are not sufficiently jagged to be able to judge the node placement across the slider. Unlike stated by yaspo they do not move at a consistent speed but accelerate towards the end instead which is not apparent from the shape and thus I would consider these unrankable under the current ruleset.
For this case that falls in line with yaspo's statement the edges are not sufficiently jagged in my opinion. To players that skin out sliderticks this is unreadable as well. Doing it like this however seems valid as the slider has a visibly thicker body to indicate the node slowdown.

LowAccuracySS wrote:

the problem with this argument is that none of the sliders in this map are actually modifying the speed in the middle of the slider. these sliders are nothing more than an aesthetic way to decrease effective sv, and aren't accelerating/decelerating at all (if they are, it may be unintentional or so minimal that it's not noticeable so I wont count it)

I mean yea the point I wanna make is that some minimal decelerating and accelerating is fine, i cant quite word it. Since on first glance of the first rule proposal, things like this could've been prohibited (due to wording ww).

---

Endaris wrote:

As a result I don't think this needs a rule but rather an additional clarification in the burai slider rule for those people that somehow lack an understanding of what "clear and visible path" means for a slider if anything.

I dont think we need to expand it more since travel speed isnt really quite related to path, the path is the thing that the sliders are shaped while travel speed is how fast we are going to aim, so I personally would go with yaspo's suggestion here.

---

I think "naturally matching" would fit where the sliders travel speed changes could be easily adapted by the player, so it could be thicker or slimmer, or if the slider has lead-ins into its travel speed changes. (This makes cases like tomoshibi no manimani fails though, but i guess its kinda frustating to play at first glance i guess)

Also we should probably mention about excessive node spams in general as it is one of our main problem here.

ChompyIsABottom wrote:

Endaris wrote:

As a result I don't think this needs a rule but rather an additional clarification in the burai slider rule for those people that somehow lack an understanding of what "clear and visible path" means for a slider if anything.

I dont think we need to expand it more since travel speed isnt really quite related to path, the path is the thing that the sliders are shaped while travel speed is how fast we are going to aim, so I personally would go with yaspo's suggestion here.

Excuse me but...What?
Sliders by definition always have the sliderball traverse them at constant speed. Any changes in perceived travel speed are made up from changes to the actual path.
I think you are mistaking the shape of the slider made up by the slider border for its path. The path is what the sliderball follows.
I made two sliders that I consider burai sliders to illustrate this and marked down the path of movement with red arrows.
First a burai slider in the traditional sense "that overlap[s itself] without straightforward slider borders":

The core technique to accelerate a slider is to make a lot of small sections going back and forth in segments so that the sliderball keeps moving back and forth in infinitesimal segments giving the visual impression that it doesn't move. By balancing the amount of "back" with the amount of "forth" the speed is controlled. The following slider should illustrate that concept:

This is pretty much exactly the same as the other slider, just with a lot more and smaller segments.
The individual segments being much smaller than for the traditional burai slider should have no influence on the application of the rule. The path made up from the red arrows is neither clear nor visible and therefore this slider is unrankable with the existing rule just like the sliders in kotoko + satorare that I mentioned.

That being said, I feel like a glossary definition for "slider path" might also serve well as clarification as this is what currently causes the diverging interpretations.

/edit: For reference the second slider with points being dragged 1 grid snap outwards in turns, creating a still somewhat questionable but much more readable shape.

hmm, I guess you have a point there. We still need to have to word the thing about excessive slider nodes spam though, as they're the main component of all this accelerating/decelerating and is also part of our main problem (sliderinator). I'll think of something later.

Currently I think of something like this:

1. Sliders must have an optimized number of anchors. Using excessive number of slider nodes could potentially break the client in the future.

However I feel like this is too ambiguous.
1. What is considered excessive?
2. If the slider is long and have complex shape, could one argue that its "not optimized" due to the slider might have lots of slider archors?
3. We probably need a definition for variable travel speed sliders so the above rule could be implemented without leaving lots of question on the back of the head.


Edit: If this is a little bit out of scope then maybe I can open up a new thread

I'm not sure if pushing a proposal for banning excessive slidernode usage in the context of sliders that already violate RC is the correct step.
There are some cool round shapes (e.g. bigger spirals on smol CS) that you can produce using maths that will also use many points. Those might be more relevant for proposing such a rule. I think using a different proposal for this would be appropriate, preferably with some research on how many nodes is too much.

On topic though, do you think that adding something like this to the glossary would benefit RC?

Slider path: The exact route of the sliderball travelling from head to tail.

Not good with wording, seems a bit difficult to make this not redundant but more clear in relation to acceleration sliders and the burai slider rule.

As for slider-node spam, probably should not be in RC on second thought, mainly because
- even something like The Sun, The Moon, The Star's slider at 10:44:721 (1) - loads properly
- seems like Lazer has a bunch of other optimization issues, especially the editor lagging on longer maps
- peppy said we can't use RC for bugs :<
So, yeah, do more research and address the issues to lazer's github.

Otherwise: woops, the glossary being a thing we can use totally slipped my mind. I did try to mash it into the existing burai rule but it didn't work out much lmao.
Using "Route" to define "Path" seems kinda weird since they're very similar words or synonyms.

Would try

Slider Path: The expected way for the sliderball to follow a slider's body from head to tail, including its travelspeed at any given point in time.

something like this?

Main goal is to use sliderbody as reference as to what the path should be. 'Expected' seemed a good idea because most burai situations are an issue because what to expect is unclear. Want to keep travelspeed or similar in there just for clarity's sake.

Hm, I think that doesn't cut it because it is not "pure" as a definition.
The burai slider rule seeks to ban sliders where the path taken by the sliderball and the path you expect the ball to take based on the shape diverge.
We also need to take this definition into account since it references the path:

Slider border: Visible outline of a slider's path. When this is distorted through overlaps, sliders can become harder to read.

-> borders overlapping make the actual path difficult to identify
Really makes it sound for me like "path" generally references the exact thing not an expectation.

Your post made me think about doing this slight change to the main line of the burai slider rule though:

Every slider must have a clear and visible path of movement to follow from start to end.

Adding "of movement" adds a differentation to a purely technical path definition putting stress on the relation of appearance and action. Might be a bit too weak with regard to the travelspeed but the speed of movement is also part of the movement so it doesn't seem so bad. I also wasn't able to come up with negative implications of such a change (yet).

endaris's thing sounds good to me.

Feel like the issue with "path" existing elsewhere would be to just be to just rename those instances to "body", I don't think that'd change the meaning of the 2 places it does occur.

I don't know if "path of movement" is super clear towards others but in context of this discussion it's pretty good yeah, especially since it keeps "path" close to its google'd definition.
If others are ok with it we should probably roll with endaris' thing imo.

im good with endaris' thing, it looks clear enough for me about the "path of movement".

also yea i agree with renaming the other two into body, if anything it kinda makes those two easier to understand and portray in mind upon reading them.

we could go with the +"of movement" in the rule, but the glossary doesn't exist anymore, so the conclusion to this thread is a little skewed

regardless, this part:

When this is distorted through overlaps, sliders can become harder to read.

didn't change my interpretation of the rule so much, so it should be okay to go as is? tbh i think it's valid without the change too, but if the 2 word addition helps others interpret it, it wouldnt hurt

edit: https://github.com/ppy/osu-wiki/pull/3608

ok I said endaris thing was good but I'm dumb and didn't read the rest of the rule

RC wrote:

Every slider must have a clear and visible path 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.

these accelerating sliders definitely fit under red definition already...

clayton wrote:

ok I said endaris thing was good but I'm dumb and didn't read the rest of the rule

RC wrote:

Every slider must have a clear and visible path 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.

these accelerating sliders definitely fit under red definition already...

Well, that's what I wrote from the start but apparently it's hard to understand for some people that these sliders overlap themselves as they only look at the effective movement which follows along the slider path without any apparent overlaps.
Personally I'm fine with the current rule so this would be a clarification proposal at best.

I'll merge with +"of movement" then, but yeah this is just clarifying what was already there.

an arguably not-so-clear clarification...

hey spoes

Ok I am a little late to this debate but thought I'd share my opinion on the matter anyways:

I don't think there should be any rules against "accelerating sliders", but rather guidelines to help shape them into a rankable format. I think they could be treated very similarly to burai sliders.

I'll go through my three reasons why I think they should be rankable:

1) They can be intuitive - one argument against these sliders is that they are unreadable, but I think that if you can introduce them into your map in an intuitive way I think these can be perfectly readable. If a map has these sliders in the intro, and uses them with very slow acceleration but noticeable acceleration, the player can pick up on this whilst not sliderbreaking.

When we look at this reasoning it also lines up to other areas of the rc, for example with hold notes (sliders that repeat but are so tiny to tell when they end) or with burai sliders. If they are introduced as a concept, the player will learn to deal with them.

It's not a complete proof since this is a WIP map, and take this with a pinch of salt because I will be doing a lot of fine tuning to make these even more intuitive, but as an example of a possible way to introduce these I will link this map: Trivecta - Talk

2) We don't know for sure if they will break in lazer - Lazer is undergoing so many changes, and in it's current state has bugs and glitches. We can't guarantee that lazer will break these sliders, and so it feels wrong to me at least, to build the RC around something that is uncertain. Dropped slider ends breaking combo happen in lazer but that will massively affect ranked maps, the truth is we are in this intermediate state where we can't be certain about will be ok and not ok in lazer, because it isn't finished. If lazer becomes more optimised then who knows maybe it will be able to then handle these sliders. Seems a bit weird for me to pre-empt that.

So to sum those two points up, I think accelerating sliders can be readable and intuitive, and as far as lazer goes I think it's unfair to limit these sliders because of it.

But to my final point,
3) I think that restricting accelerating sliders will cut off an ENTIRE field of exploring and creativity in mapping. Personally, I think that has the posibility to be devastating. The ranking criteria itself defines what is rankable, but when it limits creativity, and in my eyes I think that is what this restriction will do / is doing, I don't think it's a ranking criteria but instead just a mould. And I think that's what I disagree with most about this proposal, because I really want to see what accelerating sliders can bring to the ranked section, what creative new concepts come out of it.

Also late here, I can only comment on the "it might break lazer" part. Earlier it was mentioned that fanzhen's map crashes on lazer, this is a misattribution to other things that map does, the slider paths themselves don't cause problems. Anchor overlap is also not an issue, the rules defining when anchors merge into a red anchor and such are pretty simple and anything that changes how sliderator sliders work would also affect other rankable sliders.

The only potential forward compatibility issues are with the path rendering algorithm. In stable, the drawn path is a reduced version of the traversed path, made of ~6 osupx long segments, to reduce the rendering load. Lazer currently does not do this simplification, and therefore draws a more accurate path using more segments.

The way sliderator creates the slowdown is optimized to use the stable drawn path simplification, with many path segments that don't get drawn and add no rendering load. In lazer, it is likely that these sliders will cause lag, and will not have the same appearance, due to adding in all these normally undrawn segments.

Therefore, I would not recommend ranking this sort of slider. If we ever get sub-integer anchor placement precision, that will allow the creation of smooth accelerating sliders in a way which doesn't lag lazer, and I would re-evaluate the rankability.

performance/compatibility issues with lazer are pretty much never considered for RC because lazer should be fixing such issues. lazer shouldn't explode when playing any legacy map

regardless, this isn't being allowed for now and the restriction is already in RC