Can you explain this to me? I don't understand how old maps would be affected.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.
forum
Custom (non-2x) slider speeds re-request [Added]
posted
Total Posts
83
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.strager wrote:
Can you explain this to me? I don't understand how old maps would be affected.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.
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
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.
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.
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.
Hitcircle colours in timing sections, I agree with.
And yes, I hate maps with the wrong BPM in general because of how they screw up the graphics in the menu and Kiai.
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.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.
Hitcircle colours in timing sections, I agree with.
Support
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.
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.
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.
I'm reviving my support here as well. Lol.
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.)
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
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?
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.
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
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.
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).
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).
MM made a good point here: viewtopic.php?p=230709#p230709Skyripper 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.
^ 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.
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.
support +∞
would have been a good idea for me to have read this thread sooner.
would have been a good idea for me to have read this thread sooner.
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
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
ThisDusty wrote:
support +∞
would have been a good idea for me to have read this thread sooner.
...because the multipliers are non-2xjames039 wrote:
the Rolled map posted by MM201 though didn't confuse me one bit
Support.
I think that for a long time !!
SUPPORT !
SUPPORT !
ALL OF MY SUPPORT
As HS change doesn't work now... [So that's why my 2 songs are popped]
I should support this thing ;_;
/me = TaikOsu mapperwho loves DON
I should support this thing ;_;
/me = TaikOsu mapper
I do get annoyed when there are sudden 1/2x sections just because the songs sound softer (not slower) and i end up over sliding and breaking my combo just because my cursor went too far away. However how is this the 1/2x, 2x sections fault? it's mostly the mapper's fault for making 1/2 section on a soft portion rather than a slow down BPM. I dont agree with this
Ticks, ticks, ticks.
Changes in tick distance to provide a constant ticks/second rate would provide a visual cue to the slider's speed.
Also in many cases, if the mapper had the option of using a less harsh speed change, they would and the resulting map would be more readable and playable. Stupid breaks like what you describe would happen less if the speed change wasn't so pronounced.
I never use slider speed changes in my maps because I don't like the way osu! currently handles them for the reasons discussed in this thread. (That is, I believe tick rate must match the music, so I hate it when it changes in 2x sections, and I disagree with anything in a map being impossible to sight read.)
Changes in tick distance to provide a constant ticks/second rate would provide a visual cue to the slider's speed.
Also in many cases, if the mapper had the option of using a less harsh speed change, they would and the resulting map would be more readable and playable. Stupid breaks like what you describe would happen less if the speed change wasn't so pronounced.
I never use slider speed changes in my maps because I don't like the way osu! currently handles them for the reasons discussed in this thread. (That is, I believe tick rate must match the music, so I hate it when it changes in 2x sections, and I disagree with anything in a map being impossible to sight read.)
I've just encountered the first time where I really need this. This gets all my love and support.
Funny, I've seen at least three times cases where this is necessary in my maps. =]Larto wrote:
I've just encountered the first time where I really need this. This gets all my love and support.
I kinda need this in a good number of Taiko maps D: I can't start mapping Hakuuchou no Mizuumi without this lskadjgl;kasdhg
After thinking it over this might be a good idea, Support+1
I agree to this. 25 percent increments would be ideal for most maps. Any changes within that amount would hardly be noticable with most slider velocities.
Reasons: Certains maps just don't have regular speed changes, especially with multi BPM maps. Sometimes maps that have high velocities, have slower sections that rarely constitute cutting the speed of the section in half, because the change in tone isn't that great. It would be perfect for these kinds of maps where the mapper has to choose between having a section in their map that's either noticably too fast or too slow or changing the velocity entirely and remapping the song to a number that meets in the middle of the two numbers.
2. It gives mappers more options.
Reasons: Certains maps just don't have regular speed changes, especially with multi BPM maps. Sometimes maps that have high velocities, have slower sections that rarely constitute cutting the speed of the section in half, because the change in tone isn't that great. It would be perfect for these kinds of maps where the mapper has to choose between having a section in their map that's either noticably too fast or too slow or changing the velocity entirely and remapping the song to a number that meets in the middle of the two numbers.
2. It gives mappers more options.
Ai Uta [Oni]...
It has 1/2 slider but it can't be slider on TaikOsu with only 2x...
Ahh...
4x will help us ;_;
It has 1/2 slider but it can't be slider on TaikOsu with only 2x...
Ahh...
4x will help us ;_;
WITH A BPM OF THREE HUNDRED FORTYYYYYYYYYYYYYYYYYYY
I disagree with this. You could just as easily double the BPM for the entire song to achieve this. A section with a 4x approach rate in Taiko would be insanely disorienting.arken1015 wrote:
Ai Uta [Oni]...
It has 1/2 slider but it can't be slider on TaikOsu with only 2x...
Ahh...
4x will help us ;_;
Also this sounds more like a separate feature request: Taiko Roll Threshold. It would be very similar to Stacking Threshold and would define how long a slider must be in order to be turned into a roll instead of two notes.
Umm... Fixed with your suggestion :3MetalMario201 wrote:
Also this sounds more like a separate feature request: Taiko Roll Threshold. It would be very similar to Stacking Threshold and would define how long a slider must be in order to be turned into a roll instead of two notes.
Maybe, this request will help about HS issue anyway orz
Is... that...
OMG
OMG
ilu
yay time to go map fascination ~eternal love mix~m980 wrote:
ilu
Probably not the clearest demonstration, but what's going on here is that now that custom slider speeds have been implemented, the sections with slower slider sections now have the correct number of ticks in them. Previously, Rolled had to use different timing sections to slow the sliders down causing there to be wrongly timed ticks inside the sliders (or rather to avoid the would-be wrongly timed ticks, he just set the tick rate super low so there were no ticks at all).
[Added]Holy shit...
...HOLY SHIT.
Checked the changelog, then I was like, "...o.o" so then I checked the topic. Happy day.
OMG METALMARIO HAXED THE OSUCODE WHAT IS HAPPENING
Question!
Will this support until slider multipliers of 0.01x? I have uses for multipliers of up to 1.51x (which is an incredibly annoying prime number if multiplied by 100), so I was wondering if it will be possible
Will this support until slider multipliers of 0.01x? I have uses for multipliers of up to 1.51x (which is an incredibly annoying prime number if multiplied by 100), so I was wondering if it will be possible
Right now I have 2 digits, mainly for stuff like 0.75x, 1.25x, 1.33x, ...
The limits are from 0.5 to 2.0.
Why on Earth would you need 1.51x? Whatever it is, I couldn't possibly see it being rankable.
For the record, AIMod will throw a warning if more than 3 unique speeds are used, which is going to be the new ranking guideline.
The limits are from 0.5 to 2.0.
Why on Earth would you need 1.51x? Whatever it is, I couldn't possibly see it being rankable.
For the record, AIMod will throw a warning if more than 3 unique speeds are used, which is going to be the new ranking guideline.
;_; EkiBEN2000 has HS2.5 part :3...MetalMario201 wrote:
The limits are from 0.5 to 2.0.
I wonder if there's 0.25 ~ 4.0 orz...
NO.
Why on Earth would you need 1.51x? Whatever it is, I couldn't possibly see it being rankable.Mainly for Taiko purposes. There are some songs used in Taiko that have fluctuating BPM but the scroll speed stays constant throughout the entire song (Etude Op. 10-4).
Also, I would as much as possible like to copy the velocity changes on this chart (HS denotes the multiplier used)
Maybe you can doubles actual BPM and set x1.25 if it's Taiko Only. (Though Pipi-don will shake her arms twice more faster :3) But if you are planning TaikOsu you should reconsider to implement it.arken1015 wrote:
;_; EkiBEN2000 has HS2.5 part :3...
I wonder if there's 0.25 ~ 4.0 orz...
Yeah you can get a bit more haxy by using christmas colored timing points (red and green on top of each other); this is what I did to get K.Sai2000's x8 part (888 BPM with a 2x timing section)