forum

What are your thoughts on uninherited timing points not affecting slider velocity?

posted
Total Posts
6
Topic Starter
abraker
There is discussion going on here: https://github.com/ppy/osu/issues/10267 on whether to make uninherited timing points not affect slider velocity. The discussion initially started with focus of the mania gamemode, but it extends to all other gamemodes as well by design. What are your thoughts on this suggestion, and do you think changing the behavior will make it harder for mappers to know how to map if there was a toggle?
WitherMite
If its a toggle, why would it make it harder to map? this would make SV's in mania so much easier, instead of normalizing everything, we could just tick a box on the timing point and other gamemodes could just leave it unchecked. My question is how it would be implemented if done, would it auto normalize itself and all inherited timing points after it to the average bpm of the map, so that in the timing panel we just see 1.0x, 0.75x, 2x, etc. instead of whatever value it actually is, or straight up change how SV works altogether in relation to bpm, because I can see how that would be confusing. I also cant really tell if the toggle would be per timing point or for the whole map.

I kind of fail to see how a toggleable option would make it harder to know how to map, especially if it defaults to what it is now. i mean most new std mappers don't pay much attention to how bpm affects sv anyway and anyone who does, could probably figure out a change like this pretty easily id think.

Also, if it is more of an auto normalize button, i'd think it probably wouldn't even break older, manually normalized maps.
Uniform
this would make it much easier to make variable bpm songs, why do they even affect sv in the first place.
TheKingHenry
as long as this feature would be properly implemented in the UI, I don't see any immediate downside to this, seems like it could be handy
notBrandon
I would be okay with it if it was a toggle. If it is implemented not as a toggle but as something that is just there no matter what, many maps would break and it would limit the possibilities of [unrankable] SVs.

Some maps that may be broken by this change would be:

TWO-TORIAL - BEMANI Sound Team(PHQUASE vs DJ TOTTO) (loved)
data corruption symphony - sakuraburst (loved)
Aleph-0 (extended ver.) - LeaF
Aleph-0 - LeaF (loved)

+many others could be affected.

BUT YOU SAID TOGGLE
I would agree with a toggleable option for maps with variable BPM, still not quite sure how this would affect making SVs with uninherited lines with the toggle switched on but its something to think about.

I do think that a toggle would be a step in the right direction, I think as long as the toggle has a good info bubble when hovering over it, new mappers should be able to figure out what it does and it would make variable BPM maps less tedious.
I am in support as long as it is a toggle and red lines without the toggle on are not affected at all.
xenal
Imo could see implementation as following:

Add a "Keep slider velocity to match preview uninherited timing point" toggle in the timing panel when selecting a red line (probably could fit it in the general box). Enabled by default (current behavior).

This would be basically just a quality of life improvement and not a addition to the game. Therefore I don't really see this as an absolute most. Could be a thing in lazer, as if the lazer editor is ever going to happen.

For new mappers, this wouldn't affect anything. It doesn't change the default behavior, bpm/sv are still tied by default, and new mappers barely ever get on the timing panel (once to set their timing wrong, maybe to add greenlines if they learned how to change sv). Past the baby stage of a mapper's life, they would understand what it means.

About peppy opinion on the github link, he is completly out of touch with mapping. It doesn't change anything about mapping.
Please sign in to reply.

New reply