As title reads; this is something that's held back the creativity and polish of certain catch maps in the ranked section. Due to the way big droplets work in catch, the gameplay of a tr2 slider that is 1/3 or 1/6 turns subpar.

One example of a ranked map with this problem would be Rustyy's mapset Ahoy beatmaps/2796772, the section at 02:43:592 - all the way to 03:51:357 - is entirely 1/3, yet the rest of the map is 1/2. This creates the problem that all of the sliders in this section are both 1. completely ugly, and 2. unrepresentative of gameplay due to the big droplets being on the 1/2. I myself actually had the same problem while mapping this song, but decided to go towards tr1 due to there being no better alternatives. The solution of tr1 is a solution that lowers the potential quality of the beatmap as a whole.

An even more example of this would fall under Nelly's difficulty of Toono Gensou Monogatari beatmapsets/1474955#fruits/3026892. Starting at 00:53:934 - , a full 1/3 section starts for approximately 20 seconds until 01:11:934 - . These sliders don't represent gameplay at all by having the 1/2 slidertick be on the 1/2. Instead, for optimal gameplay these would have been much prefered to be on the 1/3 beat directly in the middle of them. There also isn't an option to really go for tr1 on this map either due to the patterning used in the earlier parts of the map 00:25:134 - completely relying on the 1/2 ticks to be there. If the bpm was allowed to be manipulated so that the TR would even out at 1/2 during the 1/3 section, the gameplay would be much better during that earlier 20 second part.

Ofcourse, all of this could be solved if we were given the solution to use multiple tickrates during a map aswell. If this could be a feasible option atleast for catch, these cases would be completely eliminated. Given the current state of lazer being a priority though, I don't think this is an option, hence why im making this proposal to allow catch maps the ability to manipulate the bpm for better slidertick usage.

This would probably come in the form of a new guideline in the catch specific section. The current reasoning this can't be done already is because of the general RC rule that lists:

Beatmaps must be perfectly timed. This means BPM and offset are exactly synchronized with the song. Beatmaps with constantly changing BPM may be impossible to perfectly time and should instead be as accurate as possible without negatively affecting gameplay. Complex timing during breaks or spinners is optional.

Along with this, the proposal linked here: community/forums/topics/1315020?n=9 would be the second step for this to work perfectly. This would allow different difficulties within the set to follow different layers. Combined with the allowance of manipulated bpm changes for sliderticks, this would allow difficulties in a beatmapset to follow everything proplerly.

TLDR; Let mappers manipulate bpm in catch maps so sliderticks aren't on 1/2 ticks during a completely 1/3 section (or just add the option for us to manually change tickrate...)

big support. tired of having to use str1 / muting sliderticks cuz there are songs that are mostly 1/2 but also have 1/3 sections

Definitely agree with Secre here since droplets on TR2 1/3 sliders doesnt represent any part of the songs at all.

The 2 suggestions he gave are actually helpful so mappers can make more interesting patterns, gives more creativity, and at the same time the map will have better presentation of the song and looks better aesthetic wise

i most certainly agree with this given that it wouldn't restrict players on slider creativity as much + it would make sliders for 1/3s or other snapped sections much more cleaner and more aesthetic making the map so much more aesthetic and clean as a whole

Eyooo this is actually quite nice to add for more creativity I down for this

Ignoring the main issue that most mappers use tick rate as an aesthetic tool anyways, implementing this sounds completely unimportant. You are asking to break one of the most important GENERAL rules in mapping for years all so your sliders can look better in small sections of drain time. There is no creative limitation and most ticks are silenced in these maps anyways. The few times that these droplets affect gameplay are when they have hypers on them or they’re involved in wiggles. I’d be willing to say that this is certain. Use tick rate 1 like standard for everything or use tick rate 2 for aesthetics and suffer the drawbacks. In lazer it looks like we can control droplet paths so we might not even need TR2 to make things look good anyways.

if there was actual support for variable str instead of being forced to multiply the bpm to a significant amount to make 1/3 work, then id consider agreeing to this rc more

I'm curious to know how using TR1, a common denominator for both 1/2 and 1/3 (and therefore the logical and trivially easy to implement solution here) "lowers the potential quality of the beatmap as a whole".

I think putting forward proposals to have variable tickrate (something that could be manipulated with inherited points in the same way as SV, hitsound sampleset, etc.) in lazer is the better way forward here, because it adds functionality and the potential for more creativity without imposing subjective bias as to what does or doesn't impact the quality of a beatmap.

JBHyperion wrote:

I'm curious to know how using TR1, a common denominator for both 1/2 and 1/3 (and therefore the logical and trivially easy to implement solution here) "lowers the potential quality of the beatmap as a whole".

I think putting forward proposals to have variable tickrate (something that could be manipulated with inherited points in the same way as SV, hitsound sampleset, etc.) in lazer is the better way forward here, because it adds functionality and the potential for more creativity without imposing subjective bias as to what does or doesn't impact the quality of a beatmap.

TR1 would remove the potential for hyperdroplets throughout a map that utilizes both 1/2 and 1/3 frequently. TR1 also just looks much worse (due to the rng droplet generation and the way sliders generally look without a big droplet). TR1 also limits gameplay potential for using TR2 big droplets on other sliders throughout the map.

I do agree that putting forward to have proposals for variable tickrates is indeed the answer for the future, but lazer is just a shitty excuse for something that has the potential to be fixed now imo. Given that stable is feature locked essentially, this is the only other avenue for implementation.

Two additional points:

1. Whether something is ugly or not is completely subjective, i.e. I don't enjoy looking at maps these days that are visually cleaned up to the point of (near) perfection.

2. Hyperdrops are a rare case.

I don't think it adds enough value to break a fundamental timing rule. Variable STR is the only way to fix the presented issues imo.

don't ticks have a hitsound as well? if the ticks are on 1/2 during a 1/3 section audio feedback would be inaccurate

full support for this, kind of want this to go to std as well

Totally agree with Secre.

as far as i know, the only drawbacks to using variable bpm for slider tick manipulation is:
- potential for abuse through making just singular sliders have a different tickrate for no reason (could easily be fixed by just the wording of the proposed rc change)
- potential for offset issues due to rounding, i know this is an issue for putting many BPM changes in a map where eventually all the rounding would make everything misalign (fixable by just, well, moving the red lines as necessary)
- very minor aesthetic issues like nightcore beats, bpm-reliant UI elements like the menu cookie, etc. (doesn't affect gameplay for the most part)

i'm in favor of the proposal just cause of how small the drawbacks are for something that is helpful, despite it fixing a relatively minor problem (in my opinion - i was never really bothered by funky sliders due to tick rate).

agree with secre, since we're def not getting a fix till lazer

regarding rounding issues, I have an idea for a new way of calculating bpm for lazer which would fix this but 1. I don't know how to code and 2. I don't know where to put it

i think you're going to have to go with tr1 in cases like this. the need for correct bpm outweighs the benefits of switching different tick rates mid-map, especially when tr1 is a very viable alternative

JBHyperion wrote:

I think putting forward proposals to have variable tickrate (something that could be manipulated with inherited points in the same way as SV, hitsound sampleset, etc.) in lazer is the better way forward here, because it adds functionality and the potential for more creativity without imposing subjective bias as to what does or doesn't impact the quality of a beatmap.

this would be the right path forward for this thread's proposal