forum

Custom (non-2x) slider speeds re-request [Added]

posted
Total Posts
83
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +0
Topic Starter
CheeseWarlock
Since I can't figure out what to do with the old topic to remove the tags, and because I keep running into situations in mapping where I wish this were possible. And as far as I can tell this request sort of got lost in the system.

The request, as MetalMario said in the original thread, is to Allow the Slider Velocity Multiplier to be specified separately for each Timing Section. Currently, there's no visual difference in sliders with different speeds, the tick rate is different, and only speeds in powers of two are supported (well, a couple maps got in before that was a rule). In a lot of cases this would be more intuitive than 2x sliders, as the changes would be both less subtle and visually communicated to the player by the placement of the slider ticks.

If you need a bit more explanation, look at the original thread.
Gabi
the original one got denied i am pretty sure. also this... i can't say i support it.
anonymous_old
I'm all for 1/2x and 2x slider speeds per timing section without changing the BPM for Taiko's sake.

I'm against anything other than 1/2x and 2x, though.
ShaggoN
While i will say that i support it. If beatmap has large bpm, and you want to make speedup slider velocity is too hard or even alomst impossible.
+1 for that
Topic Starter
CheeseWarlock
It was also Added, Confirmed and Resolved. All thanks to me (turns out you can't remove those tags)

A reason for lack of support would be nice.
anonymous_old

CheeseWarlock wrote:

It was also Added, Confirmed and Resolved. All thanks to me (turns out you can't remove those tags)
Edit the OP's topic.

CheeseWarlock wrote:

A reason for lack of support would be nice.
Difficult to read slider speed changes. Having two sliders be the same length but one is 2 beats and one is 1.5 beats? Ouch. Even 1/2x and 2x are annoying sometimes but they work because most musical symmetry (or whatever you'd call it) is 1/2x or 2x.
Topic Starter
CheeseWarlock

strager wrote:

CheeseWarlock wrote:

It was also Added, Confirmed and Resolved. All thanks to me (turns out you can't remove those tags)
Edit the OP's topic.
Been there, tried that. The tags aren't part of the subject.

strager wrote:

CheeseWarlock wrote:

A reason for lack of support would be nice.
Difficult to read slider speed changes. Having two sliders be the same length but one is 2 beats and one is 1.5 beats? Ouch. Even 1/2x and 2x are annoying sometimes but they work because most musical symmetry (or whatever you'd call it) is 1/2x or 2x.
So it can be abused. That shouldn't stop it from being added. Plus, if there's an actual musical change to suggest it and there's a slider tick to help the player follow, even that situation might work.

Musical symmetry? I don't understand exactly what you mean, but I don't think that's true. In terms of appearance 1/2x and 2x may be easier to follow, but that doesn't really relate completely to the music...
Derekku
If people are abusing it, they would be caught by modders/BATs/etc. when modding the map.
anonymous_old

Derekku Chan wrote:

If people are abusing it, they would be caught by modders/BATs/etc. when modding the map.
Plenty of abuse gets through ranking...
Gabi

CheeseWarlock wrote:

A reason for lack of support would be nice.
by musical symmetry (flow of the song?) i think he means that it would feel very unnatural to have lots of different slider speed changes. i agree with strager. also what you said about 0.5-2x sliders is untrue. i can totally relate to those changes in a song.
Derekku

strager wrote:

Derekku Chan wrote:

If people are abusing it, they would be caught by modders/BATs/etc. when modding the map.
Plenty of abuse gets through ranking...
If it's bad enough, the map could be unranked? >.>
Torran
Support~!
Topic Starter
CheeseWarlock

Gabi wrote:

by musical symmetry (flow of the song?) i think he means that it would feel very unnatural to have lots of different slider speed changes. i agree with strager. also what you said about 0.5-2x sliders is untrue. i can totally relate to those changes in a song.
Maps with a lot of slider speed changes are usually unnatural no matter what multiplier they're using. And I can't really tell you you're wrong because maybe it's more natural to you, but I find that maps like Rolled's I Can't Do It Alone [Hard] flow better than 90% of slider-speedup maps.

strager wrote:

Plenty of abuse gets through ranking...
Yeah, but the solution to that is more attentive BATs and tougher standards, not a padded-room-and-safety-scissors approach to beatmap design.
mm201
2x and 1/2x are far more disorienting than smaller changes--and they are allowed!

Allowing for speeds in between can only mitigate this problem while still allowing for sliders to change speed in keeping with the feel of the music.

Also the closer placement of ticks in slower sliders should be more than enough of a cue that this slider will move more slowly. This cue is absent in the current 2x / 1/2x implementation, where the ticks change with the speed as well!

This feature can only make the problems with current slider speed changes go away.
Gabi

CheeseWarlock wrote:

Gabi wrote:

by musical symmetry (flow of the song?) i think he means that it would feel very unnatural to have lots of different slider speed changes. i agree with strager. also what you said about 0.5-2x sliders is untrue. i can totally relate to those changes in a song.
Maps with a lot of slider speed changes are usually unnatural no matter what multiplier they're using. And I can't really tell you you're wrong because maybe it's more natural to you, but I find that maps like Rolled's I Can't Do It Alone [Hard] flow better than 90% of slider-speedup maps.
that is true. also "speed ups" are retarded. if the mapper has mapped a special instrument or sound with increased bpm, then that is fine, but when i meant that i can relate to 0.5x-2x bpm changes was when the actual song changes in bpm, and not when a random slider just changes speed. sorry for not being clear enough. songs do not split up in different BPMs, and since sliders are very BPM dependant (with or without this feature) it would make it even more unnatural for me.

i support this on one condition, and that is you can have a maximum of 2 slider velocity changes. The original one through out the map and one which can be used for some special occasion.

@metalmario201:
i fail to see how this will end the "current problem?"
anonymous_old
I'm switched to the "support" boat.

=]
0_o
I don't see why a limit of 2 slider speeds would be necessary, so long as the mapper uses the speedups/slowdowns in an intuitive way I can't think of any reasons to restrict it. Just because a feature can be abused doesn't mean it shouldn't be implemented, any abuse should be filtered out during the modding process anyway.

If this were to be implemented I think a note saying not to use different slider velocities unless you really know what you are doing would be beneficial.
Topic Starter
CheeseWarlock

Gabi wrote:

that is true. also "speed ups" are retarded. if the mapper has mapped a special instrument or sound with increased bpm, then that is fine, but when i meant that i can relate to 0.5x-2x bpm changes was when the actual song changes in bpm, and not when a random slider just changes speed. sorry for not being clear enough. songs do not split up in different BPMs, and since sliders are very BPM dependant (with or without this feature) it would make it even more unnatural for me.

i support this on one condition, and that is you can have a maximum of 2 slider velocity changes. The original one through out the map and one which can be used for some special occasion.

@metalmario201:
i fail to see how this will end the "current problem?"
I can't accept that condition. One map I have planned needs at least 3, hopefully more. And I don't think we need to set limits like that here.

It's not about the instrument OR the song having an increased BPM. In fact, that's what we're trying to solve here by making sliders not BPM-dependent. Songs, and even instruments, can "feel" faster or slower without actually changing their BPM, but it's often not enough of a change to make double or half slider speed feel natural. And in some ways these sorts of changes are like jumps, anti-jumps or spacing changes: some notes are farther away or closer than other notes with the same amount of time between them, and those can play perfectly well. The only difference is that jumps have approach circles at the end, while sliders have sliderballs to follow. Either one can be good or bad.

It solves the "current problem" of a double-speed slider looking exactly the same as a regular one.
Ephemeral
Since sliders are constructed from overlapping circles (at least as far as the background goes), if this was implemented, couldn't those circles be drawn out to the speed of the slider, so that we have a visual representation of how fast said sliders are going to travel? Assuming this isn't already the case anyway.
Topic Starter
CheeseWarlock

Ephemeral wrote:

Since sliders are constructed from overlapping circles (at least as far as the background goes), if this was implemented, couldn't those circles be drawn out to the speed of the slider, so that we have a visual representation of how fast said sliders are going to travel? Assuming this isn't already the case anyway.
That's what slider ticks are for; constructing a slider out of fewer circles would give it an irregular appearance. And it would be an awkward visual guide to rely on.
Derekku
Yeah, it's too hard to tell the length of a slider just by those circular designs.

Also, I think that peppy said in the old topic that he'd allow 3-4 different velocities per map.
anonymous_old
Please note that, as far as I remember, OpenGL sliders do not have that "many circle" design.
mm201

CheeseWarlock wrote:

It solves the "current problem" of a double-speed slider looking exactly the same as a regular one.
^

The current slider speed changes are excessively extreme and unreadable.

Allowing for smaller speed changes with ticks keeping their existing time values solves both problems. In fact, Survivor on EBA uses smaller slider speed variations and you hardly notice them. That part of the map just feels more relaxed. ("I'm better than that" 01:44:31 (9), etc. Not in the osu! version for obvious reasons.)

More relaxed sliders in more relaxed parts of the music is exactly what we want this feature for. 2x and 1/2x are just too extreme and disorienting to the player, and the doubling/halving of the ticks' time value makes them completely unreadable.

Some kind of readability for every hit object is a rule of thumb for rhythm games--one that osu! currently violates with its 2x and 1/2x sliders--one that this feature seeks to resolve.
LuigiHann
Yeah MM201 basically summed it up. Subtle slider speed changes wouldn't interfere with people's playing - most players will 300 these sliders fine without even noticing them, if they're done right. The ball moves a little faster/slower than usual, so you instinctively move your cursor a bit faster or slower, and everything's fine. It's the same as dealing with small changes in distance snap
Zekira
Support again (Taiko mapper here)
Lesjuh
Support. This map has the same thing only with 1,5x BPM timing sections http://osu.ppy.sh/forum/viewtopic.php?f=6&t=18958
FurukawaPan
support. And to be honest, I really don't care how it's implemented (this disagreement was what got it canned last time). My primary concern is being able to speed up or slow down my slider, a *little* bit, rather than the existing super over-kill 2x or 0.5x options.
mm201

james039 wrote:

support. And to be honest, I really don't care how it's implemented (this disagreement was what got it canned last time). My primary concern is being able to speed up or slow down my slider, a *little* bit, rather than the existing super over-kill 2x or 0.5x options.
Go ahead and use red timing sections, because that's what the old implementation was. You'll get the same effect.

If the old system was considered for ranking then red sections should be too.

Mind, I disagree with doing it this way because your slider ticks will end up strange.


(peppy, divide tick rate by inheritance multiplier when not 2 or 0.5, gogo!)
Topic Starter
CheeseWarlock
DO NOT "go ahead and use red ticks", that's unrankable and changing how tick rates are handled would mess up old maps or be awkwardly implemented.

Selectable slider speeds would make a much better interpretation than multiplying the BPM; that's always been a workaround, what we're after here is a feature.
mm201
This map has been deleted on the request of its creator. It is no longer available.
FurukawaPan
Inherited sections for slider speed changes are rankable, new timing sections (red) where the actual BPM didn't change is not rankable. There is currently no rankable way for me to make say, a 1.25x section. Although you may argue that technically they are the same thing, what you are doing with a new red section is changing the song timing (you have to "reset") the song timing after with a corrected red section. The inherited section conversely, allows you to just set "1x" after it's use. This is the fundamental difference, and the reason I simply cannot use an aribtrary slider speed, as the editor currently stands.

You do raise a valid point about the slider tick-rates. That might be worth taking into consideration, that an inherited BPM section affects this in an undesirable way.
mm201
This map has been deleted on the request of its creator. It is no longer available.
anonymous_old

CheeseWarlock wrote:

DO NOT "go ahead and use red ticks", that's unrankable and changing how tick rates are handled would mess up old maps or be awkwardly implemented.
Can you explain this to me? I don't understand how old maps would be affected.
LuigiHann

strager wrote:

CheeseWarlock wrote:

DO NOT "go ahead and use red ticks", that's unrankable and changing how tick rates are handled would mess up old maps or be awkwardly implemented.
Can you explain this to me? I don't understand how old maps would be affected.
It's kind of a moot point, since peppy wouldn't code anything in such a way that it would break stuff (and if he did, he'd fix it). I don't think he'd go this route anyway.
peppy
Anything synced with BPM will screw up. And yes I may change things down the track that will cause problems with said hacks, and any maps that use them will be purged.
Topic Starter
CheeseWarlock
I don't see why anything needs to be changed that will cause 1.5x (or other) BPM maps to screw up, but I have no objections to purging them for the sake of bringing them in line with modern standards once this gets implemented.

This is probably more controversial, but it would be pretty awesome if other things (especially approach circle time) could be changed per-section too. It would be abused pretty badly, but I can think of exactly one map concept that would make use of it. :cry:
mm201
For the record, I never agreed with the idea of using red sections for slider speeds. All the associated quirks are why I requested this feature in the first place.

And yes, I hate maps with the wrong BPM in general because of how they screw up the graphics in the menu and Kiai.

CheeseWarlock wrote:

This is probably more controversial, but it would be pretty awesome if other things (especially approach circle time) could be changed per-section too. It would be abused pretty badly, but I can think of exactly one map concept that would make use of it. :cry:
Let's keep this thread on-topic if at all possible. Feel free to request this in its own thread, but I, personally, don't support it. I find it annoying and confusing when this happens in Taiko and DDR.

Hitcircle colours in timing sections, I agree with.
m980
Support
Babble
I support 100%
mm201
Two things:

1. Since the broken Custom Multiplier implementation was removed, a couple of the issues which broke it have been fixed. Specifically, Beat Snap Divisors and Kiai Flashes now ignore inheritance sections.

2. An old bug revealed that the beatmap object model keeps track of slider tick rates independently for timing sections. In this old bug, when changing the tick rate in a song with many timing sections, only the current section would refresh. For this bug to happen, tick rates (or some calculated value based on them) must be stored for each timing section.


Using these two facts, I propose a very easy, straightforward implementation of this feature: Bring back the old Custom Multipliers with the improvements of (1), obviously. Then, change the way tick rates are calculated for timing sections using them to be SectionTickRate = MapTickRate / CustomMultiplier.

(Optionally, leave out this last step for multipliers of 0.5 or 2, or otherwise do some old map detecty thingy like with stacking to keep existing maps the same.)

This will fulfill every point of this request.
Zekira
I don't know exactly about the details of 1.) from above since I never experienced the test build of that, but from what I can understand is that the custom slider broke those 2 major things from mapping. With those answered then maybe it would be safer to implement such now (since Taiko really needs it orzorzorz) while agreeing with the same formula that MM201 has given.

I'm reviving my support here as well. Lol.
mm201
The old, broken implementation can actually still be used if you edit the .osu file in Notepad. Of course, this is unrankable because the implementation is subject to change.

It does reveal that there are only two remaining issues:
1. The ticks.
2. i134 - Slider length snap incorrect for inherited sections with BPM multipliers

(Also putting the UI back in the timing panel, obviously.)
Topic Starter
CheeseWarlock
I think that the best way to go is to make the new speed changes a completely different implementation, allowing "change the slider speed" while leaving "double/halve the BPM" available as a legacy feature and for backwards compatibility. As I recall, the only way it was ever implemented was allowing any BPM multiplier, and why make mapping so counterintuitive?
mm201
I suspect peppy would have written it this way in the first place if it was that easy.

I'd blindly figure that doing this would require a substantial framework refactor. Like, maybe timing sections are outside the accessibility scope of slider calculation.

And as long as it's presented to the user as "slider speed modification" and behaves in an expected way, it should be fine.
Topic Starter
CheeseWarlock
That may be true, but I think it's still best to keep things clean behind the scenes even if it requires more work (or for those of us who aren't peppy, more time) to implement. If what is listed as the BPM is actually the (BPM * slider speed) we're just asking for trouble in terms of future expansion.
Skyripper
There is truly no need for variety beyond .5x, 1x and 2x slider speeds. Beatmaps with more variety than that (and even some with as much variety currently provided) would be confusing.

Now, if what you mean is you want a speed that would EQUATE to 1.25x slider speed based on your initial slider speed, simply don't use your initial and switch it to the desired speed (since you apparently won't be using the first speed anyway).
anonymous_old

Skyripper wrote:

There is truly no need for variety beyond .5x, 1x and 2x slider speeds. Beatmaps with more variety than that (and even some with as much variety currently provided) would be confusing.
MM made a good point here: viewtopic.php?p=230709#p230709
mm201
^ This.

Also, confusion with slider speed changes actually work the opposite way to what you describe, Skyripper. Basically, there's going to be a certain reaction delay between when you start hitting a slider and when you realize it's going at a different speed. (Assuming you're ignoring the ticks cue I already discussed.)

If, by the time you've clued in that the slider is moving differently, the ball has moved too far away from your cursor, you break your combo. But if it's still fairly close to the cursor, you'll correct and things will be fine.

For the average experienced player, this reaction time will allow for a slider to be sped up by as much as 1.5x or so. Any faster and the player is prone to screw it up. So 2x is too fast.

Don't tell me you've never broken your combo by moving your mouse too slow/fast when a 2x / 0.5x slider shows up.

If you're still not convinced, play this map and see how the speed changes aren't confusing in any way.

Edit: Hmm, .osu files store everything slider-related as distances/lengths:

TickDistance = (-10000 * SliderMultiplier) / (TickRate * InheritBpmValue)
Values as they appear in the .osu files.

Also i134.

Tick distances are stored per slider anyway, so just calculate them in this way.
Dusty
support +∞

would have been a good idea for me to have read this thread sooner.
FurukawaPan
Still support,

the Rolled map posted by MM201 though didn't confuse me one bit, so I posted another map where I can't hardly play due to slider speed variations being too drastic. http://osu.ppy.sh/b/29294

Gonna go practice some more :P
show more
Please sign in to reply.

New reply