I think this post should at Feature Request. Why it here? lol 
forum
[Rule Change] Slider Velocity multipliers usage.
posted
Total Posts
153
u mad
Kodora
It was actually, but moved here.Oyatsu wrote:
I think this post should at Feature Request. Why it here? lol
Also one map what i always forgot to post
https://osu.ppy.sh/b/210313 - How intuitive and amazing map can be. 02:28:098 (1) - this slider used x0.25 speed. Just listen to music at this part - this slider absolutely mach song here, gives feeling of this sudden bass note here, feeling of this song. Not like it can be replaced with "hold" or something, this slider is totally playable and feels just awesome on this part.
I did.HakuNoKaemi wrote:
i didn't post an example
I said my entry for the contest had some sections sv multiplier edited from the .osu
Kodora
http://osu.ppy.sh/b/160376 (Excorrupt diff) - Slowdows sections fully mapped using x0.13 SV and it works as much better alternative for x0.50
https://osu.ppy.sh/b/150366&m=1 <- Coward Haku
02:22:384 (6) - In my guest, 0.38x is the half of x0.75 ( half is x0.375 ~ x0.38). Though I used some unrankable sliders
02:22:384 (6) - In my guest, 0.38x is the half of x0.75 ( half is x0.375 ~ x0.38). Though I used some unrankable sliders
Kodora
Since i see this map really first time i asked some people with different skill level to play it. I played it too. All was have only one try. Noone was know this map beforeHakuNoKaemi wrote:
https://osu.ppy.sh/b/150366&m=1 <- Coward Haku
02:22:384 (6) - In my guest, 0.38x is the half of x0.75 ( half is x0.375 ~ x0.38). Though I used some unrankable sliders
Results
Those sliderspeed manipulations done very intuitive, and noone even noticed that here was x0.38 slider. Good example of rational usage.
Those sliderspeed manipulations done very intuitive, and noone even noticed that here was x0.38 slider. Good example of rational usage.
Haku, you might want to find an actual good example. I glanced at the judge comments for your entry, and they -all- found it to be a poor use.
https://osu.ppy.sh/p/contestresults?e=100
https://osu.ppy.sh/p/contestresults?e=100
SPOILER
Moreover, extremely slow sliders do play as holds, because the cursor effectively stays in one place. There could be a very slight motion with shorter sliders, but that doesn't change the hold-like feel. Wait for actual holds, which provide feedback. Longer sliders feel tedious and useless to me, as well as feeling like they're mapped over useless parts.
As for my experience, more than two years, including my experience with 2008 maps and the DS games, has given me pretty much everything that I need to know and then some. Amount of time or status != right, especially because I could make a strong case for becoming a BAT if I were to push for it. Also, my point about the people who might be opposed to this was aimed at pieguy's statement of "hey look how many people like this, this clearly means that everybody likes it!" A tiny fraction of the community have shown their support.
I'm taking the liberty of having a look at these examples, but the download limit's making the process very slow. Let it be said that my aggressive tone is only me being assertive in the face of people who assume that I have no basis for my opinion. Let's start with pieguy's examples!
First map: pieguy posting one of his maps as "evidence." No bias here!
The extremely slow slider is tedious and mapped over pretty much nothing. It feels thoroughly useless. The speedup after it is obscene and would not be rankable. You people can already change the .osu for gimmick maps, so you can make silly gimmicks like this for standalone maps. They won't be ranked anyway.
The second example is ridiculous. The last kickslider makes it hard to tell if it's even possible to hold the cursor in place, but it's quite a narrow margin anyway. Moreover, all of the sliders look like they could have the same duration. The map would not be rankable in the slightest.
worldenddominator: Not good. Utterly unreadable. The tiny slider looks like it'd last for a sixteenth note. The sweeping motion of the note could be expressed far, far better by a long wave or, you know, one of those silly scrunched up sliders. What follows the tiny slider is a horrible example of flow, readability, presentation and pretty much everything which good mapping entails. Even worse, the whistle makes it feel even more ludicrous.
'FLOWER': Unreadable nonsense. A spinner or even blank space would make much more sense in the first part. The other example is kind of cute, but it's an unfair trap after the horrendous mess before it. An actual hold circle would be good, or just ending the section on beat one.
'Metomorphasis': I remember playing this map a while ago and not enjoying the experience. In fact, it does a lot wrongly besides the slowdown. That slowdown also comes out of nowhere and it's occurring over a decay. I'd leave silence there. It also ends on a strong downbeat, which weakens the start of the next section.
'MATERIAL': Those sliders were achieved by lowering the BPM, which is the most sensible way because of the song's ritardando. I'd say that it'd make more sense to leave some space anyway, since the piano finishes in a satisfying place. Not to mention, the speedup after the pause is ridiculous, which is even more reason to let the player actually rest/centre their mouse.
'Nyaruko Marathon': Colourhax does nothing for the readability. The changes also sent my mouse hand flapping around and then it was hard to get back into the map. I only managed to hit them because I knew that they were coming. Unfair traps.
'Roze': I've played this map already and it's one of many severe examples which make me extremely sceptical. I didn't enjoy it--just because the song's emotional, it doesn't mean that the map has to be a flailing mess.
'CaptivAte': Lesjuh can do some weird things. This is one of them. The discrepancy between the huge jumps and the nigh-dead slider is ridiculous and the slider also weakens the last beat in a very bad way.
Couple of more that I've missed. All of the above considers musicality and playability/readability.
Honestly, guys, you're trying to prove to peppy and possibly mm that there's a use for the changes. These are not good examples. I'm pretty sure that peppy would feel the same. His hands are full with loads of other commitments as it is. mm would certainly detest what's being posted.
I know enough about music and pacing to form a competent opinion. I've also spoken to plenty of competent mappers/the people who code this game who agree with me/would agree with me. It's not bias for the sake of bias--it's me seeing quite a significant number of examples of bad pacing/unreadability. They just don't work and would not be rankable.Zarerion wrote:
[Stuff about me projecting my opinion]
Moreover, extremely slow sliders do play as holds, because the cursor effectively stays in one place. There could be a very slight motion with shorter sliders, but that doesn't change the hold-like feel. Wait for actual holds, which provide feedback. Longer sliders feel tedious and useless to me, as well as feeling like they're mapped over useless parts.
As for my experience, more than two years, including my experience with 2008 maps and the DS games, has given me pretty much everything that I need to know and then some. Amount of time or status != right, especially because I could make a strong case for becoming a BAT if I were to push for it. Also, my point about the people who might be opposed to this was aimed at pieguy's statement of "hey look how many people like this, this clearly means that everybody likes it!" A tiny fraction of the community have shown their support.
I'm taking the liberty of having a look at these examples, but the download limit's making the process very slow. Let it be said that my aggressive tone is only me being assertive in the face of people who assume that I have no basis for my opinion. Let's start with pieguy's examples!
First map: pieguy posting one of his maps as "evidence." No bias here!
The extremely slow slider is tedious and mapped over pretty much nothing. It feels thoroughly useless. The speedup after it is obscene and would not be rankable. You people can already change the .osu for gimmick maps, so you can make silly gimmicks like this for standalone maps. They won't be ranked anyway.
The second example is ridiculous. The last kickslider makes it hard to tell if it's even possible to hold the cursor in place, but it's quite a narrow margin anyway. Moreover, all of the sliders look like they could have the same duration. The map would not be rankable in the slightest.
worldenddominator: Not good. Utterly unreadable. The tiny slider looks like it'd last for a sixteenth note. The sweeping motion of the note could be expressed far, far better by a long wave or, you know, one of those silly scrunched up sliders. What follows the tiny slider is a horrible example of flow, readability, presentation and pretty much everything which good mapping entails. Even worse, the whistle makes it feel even more ludicrous.
'FLOWER': Unreadable nonsense. A spinner or even blank space would make much more sense in the first part. The other example is kind of cute, but it's an unfair trap after the horrendous mess before it. An actual hold circle would be good, or just ending the section on beat one.
'Metomorphasis': I remember playing this map a while ago and not enjoying the experience. In fact, it does a lot wrongly besides the slowdown. That slowdown also comes out of nowhere and it's occurring over a decay. I'd leave silence there. It also ends on a strong downbeat, which weakens the start of the next section.
'MATERIAL': Those sliders were achieved by lowering the BPM, which is the most sensible way because of the song's ritardando. I'd say that it'd make more sense to leave some space anyway, since the piano finishes in a satisfying place. Not to mention, the speedup after the pause is ridiculous, which is even more reason to let the player actually rest/centre their mouse.
'Nyaruko Marathon': Colourhax does nothing for the readability. The changes also sent my mouse hand flapping around and then it was hard to get back into the map. I only managed to hit them because I knew that they were coming. Unfair traps.
'Roze': I've played this map already and it's one of many severe examples which make me extremely sceptical. I didn't enjoy it--just because the song's emotional, it doesn't mean that the map has to be a flailing mess.
'CaptivAte': Lesjuh can do some weird things. This is one of them. The discrepancy between the huge jumps and the nigh-dead slider is ridiculous and the slider also weakens the last beat in a very bad way.
Couple of more that I've missed. All of the above considers musicality and playability/readability.
Honestly, guys, you're trying to prove to peppy and possibly mm that there's a use for the changes. These are not good examples. I'm pretty sure that peppy would feel the same. His hands are full with loads of other commitments as it is. mm would certainly detest what's being posted.
SPOILER
read sliderticks?
and/or accept the fact that a map does not necessarily need to be sightreadable for everyone on the very first try?
(also consider that every player has different reading abilities thus it's easier for different people)
How about for once we stop stupid discussions and just try some stuff? Let's just give people, i.e. mappers, the chance to do things their way and see how it works out (hint: It won't be bad). If like everyone agrees that suddenly a shitton of maps use 0.00001 Sliders at speedup kiai parts (hint: this won't happen, mappers will be cautious about using such low SV) we can still change it back.
and/or accept the fact that a map does not necessarily need to be sightreadable for everyone on the very first try?
(also consider that every player has different reading abilities thus it's easier for different people)
How about for once we stop stupid discussions and just try some stuff? Let's just give people, i.e. mappers, the chance to do things their way and see how it works out (hint: It won't be bad). If like everyone agrees that suddenly a shitton of maps use 0.00001 Sliders at speedup kiai parts (hint: this won't happen, mappers will be cautious about using such low SV) we can still change it back.
Kodora
I was sure that we have Beatmap Appreciation Team here to judge playability of every map what pretended to be ranked, isnt it? As a modder you have rights to say your personal opinion about mapping technique what you see but we have special qualified members to judge is it playable or not. Playability discussion have no place for personal opinions. I'm just going to quote ykcarrot here:D33d wrote:
Kodora, your examples would not jibe well with a lot of people and I'd say that it extends to BATs.
Well, lets talk about as minimum 2 my examples:ykcarrot wrote:
Don't slander the mapper just because it doesn't fit your taste.
1) Cry for Eternity - https://osu.ppy.sh/s/27448
I just probably will only leave link to Colin Hou's post - p/801880 - playability confirmed by BATs
2)DJ YOSHITAKA - CaptivAte Compilation - https://osu.ppy.sh/s/29705
Even if Dangaard refused to bubble due to this he confirmed that they works with map just awesome - even not going to talk about another BATs what bubbled it before and after.Dangaard wrote:
the slow sections are codehacked, and as much as this works with the map, it's said to be unrankable and not implemented in the editor... minimum is x0.5
If you want, i can response to every your opinion and prove playability by all of them, but i'm not a qualified member. So please, just wait.
Kodora
please dont remove this post since it about compromise what we all decided to keep
I did short discussion with D33d about Garven's suggestion:
According to this, i'll change topic and first post right now.
EDIT: Changed first post. Any suggestions to improve current wording are welcome.
I did short discussion with D33d about Garven's suggestion:
Wise speedchange usage requires very, very good mapping experiense, especially if mapper decided to cross current limitation. However, in specified cases it may works, and works enough intuitive and playable. Together we decided to follow Garven's suggestion about allowing editing .osz for speedchanges for specified cases. Any abusely usage can be prevented by popping/unranking over quality reason (unreasonable SV changes usage for this case), but good usage may chance to get ranked/approved category.Garven wrote:
Considering how infrequent this would be used, it would be better to amend the editing of osu files rule then continue this movement to allow going beyond the constriction in special cases.
Here is chatlog
23:20 Kodora: o hi
23:20 D33d: Sup.
23:22 Kodora: Do you have so free time to discuss something?
23:22 D33d: Depends on how much discusson's needed.
23:23 Kodora: I think it would be nice to discuss theory aspects via PM (feel free to post log in thread if you want) instead of posting in thread
23:23 Kodora: Its about new SV changes
23:23 D33d: I know.
23:23 D33d: I don't want to talk about it much, because I've said all that I wanted in the thread.
23:23 Kodora: I understand fact that not all people agree with it.
23:23 Kodora: I understand fact that not all people even like any SV manipulation
23:24 D33d: I get that those things are fun to some people, but it's about compromise and not using nasty traps.
23:24 Kodora: We can do a nice compromise. I discussed with Garven before about this.
23:24 D33d: Yeah he'd mentioned that.
23:25 D33d: I only argued my case so intensely because I've seen all of this stuff loads of times and it's never worked for me.
23:25 D33d: That and I've never seen a case which couldn't have been replaced by something else.
23:26 D33d: It's not between us anyway. It's between the supporters and peppy, which is why all of the further discussion was deleted.
23:26 Kodora: As Garven said pm to me, using any SV changes need enough well experience at mapping, and really only few mappers can do it, especially with highest one.
23:26 D33d: Basically that. Discretion and limits are important.
23:26 Kodora: But, it can be done well case-by-case
23:27 D33d: The problem is that it becomes extremely hard to justify.
23:27 Kodora: All rules have exceptions. We cant absolute anything in this universe.
23:27 Kodora: Lets just do one simple compromise:
23:27 D33d: Some of those examples had a nice effect, but contrasted too much and too suddenly.
23:28 D33d: osu! rules can be broken in some cases, but rules are there for a reason.
23:28 Kodora: It wont be implimented in editor, but will be allowed via manual editing .osz for specified cases. If any BAT member will disagree with it, it will be popped over not reasonable usage with constructive suggestions about good replacement.
23:29 Kodora: Or unranked
23:29 D33d: Really, anybody can do that already, right?
23:29 D33d: It's only an editor limitation and, since the use cases are special, people can invoke them when they really want to.
23:30 D33d: I agree with it being allowed at all if it's really effective.
23:31 Kodora: Not really. Only few people know how it can be done. If people can do it in well, reasonable and playable well and playability of this usage will be confirmed by qualified member it will be added to official list of ranked maps.
23:31 Kodora: Thats my idea how it will works.
23:31 D33d: I thought that was always the case.
23:31 D33d: Remind me if there's a rule against it.
23:32 Kodora: We just going to cancel one limitation for specifical case on a legit way, nothing more.
23:32 D33d: Honestly, I'm happy as long as it stays out of the editor.
23:33 Kodora: In fact we really have no any rules about "do not set speedchanges over current editor limit" (yes it can be done without manual editing .osz)
23:33 D33d: Yes, speedchanges can be made with BPM changes.
23:33 Kodora: But to make it clean i think would be nice to have an official exception.
23:33 Kodora: I mean not this.
23:34 Kodora: Speedchanges over current limit can be done just by switching to osu!mania editor moe.
23:34 D33d: Well that's still not allowed and all, but if a song actualy changes its speed, BPM can be changed like that anyway.
23:34 D33d: I still thought that there was always a caveat for it.
23:34 Kodora: *mode
23:34 D33d: Oh okay.
23:34 Kodora: I dont like any BPM manipulations honestly
23:34 D33d: They tend to be bad yeah, if they're done to force something.
23:36 D33d: Mappers only need to understand that extreme gimmicks are likely to be modded out.
23:36 Kodora: One important thing: this discussion was started again because with new osumania editor we can avoid this rule. So, to make it clean and avoid any missunderstanding, i think would be nice to follow Garven's suggestion.
23:36 D33d: I.e. it doesn't have to be a huge issue if massive changes aren't allowed by a BAT.
23:37 D33d: I think that people really need to treat standard and mania as completely separate games.
23:37 Kodora: Its a good compromise what already accepted several BATs.
23:37 D33d: Pretty much.
23:39 Kodora: If there are any BATs what will be against speedchanges usage they have all powers to pop/unrank abusely map over this reason.
23:39 Kodora: Like they exactly doing it now for other problematic maps
23:39 D33d: Exactly.
23:40 D33d: Keeping the case as it is now, we won't have too much abuse and people can still go out of their way if they want.
23:40 D33d: Thanks for being forthcoming about it.
23:41 Kodora: So, you agree with Garven's propose?
23:43 Kodora: I'll just edit first post according to it
23:44 D33d: Yeah I agree.
23:45 Kodora: Then nice. Thanks for discussion, i'll post log :p
23:45 D33d: Sorry for getting so fired up too. I saw all of the bickering and kind of lost it.
23:45 D33d: Plus, I gave all of the reasons I could, so I know that I can leave it be.
23:46 Kodora: :3
23:20 D33d: Sup.
23:22 Kodora: Do you have so free time to discuss something?
23:22 D33d: Depends on how much discusson's needed.
23:23 Kodora: I think it would be nice to discuss theory aspects via PM (feel free to post log in thread if you want) instead of posting in thread
23:23 Kodora: Its about new SV changes
23:23 D33d: I know.
23:23 D33d: I don't want to talk about it much, because I've said all that I wanted in the thread.
23:23 Kodora: I understand fact that not all people agree with it.
23:23 Kodora: I understand fact that not all people even like any SV manipulation
23:24 D33d: I get that those things are fun to some people, but it's about compromise and not using nasty traps.
23:24 Kodora: We can do a nice compromise. I discussed with Garven before about this.
23:24 D33d: Yeah he'd mentioned that.
23:25 D33d: I only argued my case so intensely because I've seen all of this stuff loads of times and it's never worked for me.
23:25 D33d: That and I've never seen a case which couldn't have been replaced by something else.
23:26 D33d: It's not between us anyway. It's between the supporters and peppy, which is why all of the further discussion was deleted.
23:26 Kodora: As Garven said pm to me, using any SV changes need enough well experience at mapping, and really only few mappers can do it, especially with highest one.
23:26 D33d: Basically that. Discretion and limits are important.
23:26 Kodora: But, it can be done well case-by-case
23:27 D33d: The problem is that it becomes extremely hard to justify.
23:27 Kodora: All rules have exceptions. We cant absolute anything in this universe.
23:27 Kodora: Lets just do one simple compromise:
23:27 D33d: Some of those examples had a nice effect, but contrasted too much and too suddenly.
23:28 D33d: osu! rules can be broken in some cases, but rules are there for a reason.
23:28 Kodora: It wont be implimented in editor, but will be allowed via manual editing .osz for specified cases. If any BAT member will disagree with it, it will be popped over not reasonable usage with constructive suggestions about good replacement.
23:29 Kodora: Or unranked
23:29 D33d: Really, anybody can do that already, right?
23:29 D33d: It's only an editor limitation and, since the use cases are special, people can invoke them when they really want to.
23:30 D33d: I agree with it being allowed at all if it's really effective.
23:31 Kodora: Not really. Only few people know how it can be done. If people can do it in well, reasonable and playable well and playability of this usage will be confirmed by qualified member it will be added to official list of ranked maps.
23:31 Kodora: Thats my idea how it will works.
23:31 D33d: I thought that was always the case.
23:31 D33d: Remind me if there's a rule against it.
23:32 Kodora: We just going to cancel one limitation for specifical case on a legit way, nothing more.
23:32 D33d: Honestly, I'm happy as long as it stays out of the editor.
23:33 Kodora: In fact we really have no any rules about "do not set speedchanges over current editor limit" (yes it can be done without manual editing .osz)
23:33 D33d: Yes, speedchanges can be made with BPM changes.
23:33 Kodora: But to make it clean i think would be nice to have an official exception.
23:33 Kodora: I mean not this.
23:34 Kodora: Speedchanges over current limit can be done just by switching to osu!mania editor moe.
23:34 D33d: Well that's still not allowed and all, but if a song actualy changes its speed, BPM can be changed like that anyway.
23:34 D33d: I still thought that there was always a caveat for it.
23:34 Kodora: *mode
23:34 D33d: Oh okay.
23:34 Kodora: I dont like any BPM manipulations honestly
23:34 D33d: They tend to be bad yeah, if they're done to force something.
23:36 D33d: Mappers only need to understand that extreme gimmicks are likely to be modded out.
23:36 Kodora: One important thing: this discussion was started again because with new osumania editor we can avoid this rule. So, to make it clean and avoid any missunderstanding, i think would be nice to follow Garven's suggestion.
23:36 D33d: I.e. it doesn't have to be a huge issue if massive changes aren't allowed by a BAT.
23:37 D33d: I think that people really need to treat standard and mania as completely separate games.
23:37 Kodora: Its a good compromise what already accepted several BATs.
23:37 D33d: Pretty much.
23:39 Kodora: If there are any BATs what will be against speedchanges usage they have all powers to pop/unrank abusely map over this reason.
23:39 Kodora: Like they exactly doing it now for other problematic maps
23:39 D33d: Exactly.
23:40 D33d: Keeping the case as it is now, we won't have too much abuse and people can still go out of their way if they want.
23:40 D33d: Thanks for being forthcoming about it.
23:41 Kodora: So, you agree with Garven's propose?
23:43 Kodora: I'll just edit first post according to it
23:44 D33d: Yeah I agree.
23:45 Kodora: Then nice. Thanks for discussion, i'll post log :p
23:45 D33d: Sorry for getting so fired up too. I saw all of the bickering and kind of lost it.
23:45 D33d: Plus, I gave all of the reasons I could, so I know that I can leave it be.
23:46 Kodora: :3
According to this, i'll change topic and first post right now.
EDIT: Changed first post. Any suggestions to improve current wording are welcome.
It's multipliers, not multiplier. Change that and add these changes.
Kodora
Kodora
Sound exactly perfect, those "dont use more than 3 SV's" guideline was weird anyway, this correction is much more reasonable.HakuNoKaemi wrote:
The rule's already permitting to edit .osu to manually edit sv speeds, like this.
So, let's divide the guideline in two parts
one pertaining the numbers of multipliersA reasonable amount, generally three(excluding tiny velocity shifts made to correct the length of some sliders), of slider velocity multipliers should be used.(Examples: 0.5x, 1.0x and 2.0x or 0.75x, 1.00x and 1.5x, but not 1.00x, 0.98x and 1.02, since they're tiny enough to not be a real change). If slider velocity changes are able to be merged (e.g. close values like 0.8x and 0.7x) while still flowing/working correctly, then they should be.and another pertaining the range of usable multipliersWhile you can generally use a good range of slider velocity multipliers(from 0.5x to 2.0x), you can manually edit the .osu file to obtain an unlimited range of multipliers. When using slider velocity multipliers obtained like this, try to test them with an handful of peoples with various skill levels (dependent on the difficulty of the map) to know if the way you used the slider velocity change played good.
Updated first post.
I just want to give my 2c about this.
The reason I believe a huge velocity change isn't necessary is because when mapping you should care about presentation. You don't have to have really big changes to make an object represent something in the music, little things can work much better, because they are subtle. That is what makes maps interesting in my opinion. Constantly changing speeds or having really drastic changes can be "cool" but that's all there is to it. The playability suffers (though this can be intentional).
What I do agree with is that the base SV is too limited currently, and should be bigger, simply because of another issue and that is the BPM. There are songs which are very active and uplifting and yet their BPM is too low. There are songs with like 140 BPM which can easily get mapped with AR9 (and possibly with AR10, provided they are actually mapped like 280 BPM because it fits), and yet they can't get mapped properly without using a static multiplier over a base SV. This is a very rare problem, but it exists. 1/8 can easily exist in the music.
What I propose is that instead of changing a very logical rule, we just expand how multipliers work. Base SV should be able to go over 3,60 (possibly around 4.4 or maybe even 5) and the multipliers should be allowed to reach 0.25x and 2.5x. However, the usage of those should still be moderate, meaning that intentionally doubling SV and then halving it through the entire map just to get one 4x SV slider should not be allowed.
This will allow any kind of representation and I don't think you really need more. This can open enough creativity to create more different things (and things some people consider fun, I don't though) and yet it will still be in moderation. Changes don't have to be really drastic to work. We can always gradually work things out, just like some other rules have.
Though, this means that this becomes a feature request instead. The rules around this are perfectly fine, however the limitations seem outdated. This is why I suggest we don't discuss the change of that rule because it really makes sense, and instead focus on expanding the limitations of the SV itself.
The reason I believe a huge velocity change isn't necessary is because when mapping you should care about presentation. You don't have to have really big changes to make an object represent something in the music, little things can work much better, because they are subtle. That is what makes maps interesting in my opinion. Constantly changing speeds or having really drastic changes can be "cool" but that's all there is to it. The playability suffers (though this can be intentional).
What I do agree with is that the base SV is too limited currently, and should be bigger, simply because of another issue and that is the BPM. There are songs which are very active and uplifting and yet their BPM is too low. There are songs with like 140 BPM which can easily get mapped with AR9 (and possibly with AR10, provided they are actually mapped like 280 BPM because it fits), and yet they can't get mapped properly without using a static multiplier over a base SV. This is a very rare problem, but it exists. 1/8 can easily exist in the music.
What I propose is that instead of changing a very logical rule, we just expand how multipliers work. Base SV should be able to go over 3,60 (possibly around 4.4 or maybe even 5) and the multipliers should be allowed to reach 0.25x and 2.5x. However, the usage of those should still be moderate, meaning that intentionally doubling SV and then halving it through the entire map just to get one 4x SV slider should not be allowed.
This will allow any kind of representation and I don't think you really need more. This can open enough creativity to create more different things (and things some people consider fun, I don't though) and yet it will still be in moderation. Changes don't have to be really drastic to work. We can always gradually work things out, just like some other rules have.
Though, this means that this becomes a feature request instead. The rules around this are perfectly fine, however the limitations seem outdated. This is why I suggest we don't discuss the change of that rule because it really makes sense, and instead focus on expanding the limitations of the SV itself.
AiMod could mention unrecommended SV changes. It would make modding it easier. The same could be applied to 1/12th and 1/16ths notes.
Deleted posts which didn't contain examples or responses to examples. Hid some which were walls-of-text i would feel guilty deleting, but take that as a warning.
Kodora
It actually was a feature request (to allow SV multipliers from osu! mania mode for osu standard) but moved here. I agree with your suggestion very much (however i'd discuss more SV limitation because i already linked linked map what uses x0.13 slider and its works well, + if people can create enough playable x4 slider why should we stop them from rank?). It was reverted to rule change thread due to potential rarely usage of it and because some people was asking for unlimited SV.lolcubes wrote:
What I propose is that instead of changing a very logical rule, we just expand how multipliers work. Base SV should be able to go over 3,60 (possibly around 4.4 or maybe even 5) and the multipliers should be allowed to reach 0.25x and 2.5x. However, the usage of those should still be moderate, meaning that intentionally doubling SV and then halving it through the entire map just to get one 4x SV slider should not be allowed.
This will allow any kind of representation and I don't think you really need more. This can open enough creativity to create more different things (and things some people consider fun, I don't though) and yet it will still be in moderation. Changes don't have to be really drastic to work. We can always gradually work things out, just like some other rules have.
Though, this means that this becomes a feature request instead. The rules around this are perfectly fine, however the limitations seem outdated. This is why I suggest we don't discuss the change of that rule because it really makes sense, and instead focus on expanding the limitations of the SV itself.
The practice of using this new rule should show potential new SV limitatins to create this new feature what you mentiored, but, as Garven said, changing this rule is probably onliest way to change something for now.
Not sure about this, unrecommended SV changes isnt real problem as long as they works well (if it plays bad modders will noticed this just by testplay) and sadly some modders just blindly copy everything what AIMod/AIBAT says.TheVileOne wrote:
AiMod could mention unrecommended SV changes. It would make modding it easier.
I don't consider that a bad thing. AiMod should mention anything that violates a guideline. For convenience experienced modders should be able to check AiMod and know where all the violations are in a map. Newbie modders either already know not to blindly mention things in AiMod or not know what it is used for, because they don't mention non-sense Kiai issues that AiMod points out all the time in maps.
Remember that the mapper needs a good reason to break a guideline. The modder should be considering whether going below 0.5x is necessary and better than using 0.5x. It is so much easier to just ignore the issue completely. It would be nice to see AiMod point out this issue, because it should be unrankable under the current rules, and newer modders should have a place to look for potential issues and make their own judgments. They aren't going to know that it's a guideline or trust their own opinion enough to say it should be changed.
Newbies tend to blindly make changes to their maps. It would be good if a newbie modder blindly points this issue out on a newbie map. It is likely that the newbie will listen and use a different slider velocity.
I don't want to cause a large discussion about this. Is peppy going to decide personally whether this is going to be allowed?
Remember that the mapper needs a good reason to break a guideline. The modder should be considering whether going below 0.5x is necessary and better than using 0.5x. It is so much easier to just ignore the issue completely. It would be nice to see AiMod point out this issue, because it should be unrankable under the current rules, and newer modders should have a place to look for potential issues and make their own judgments. They aren't going to know that it's a guideline or trust their own opinion enough to say it should be changed.
Newbies tend to blindly make changes to their maps. It would be good if a newbie modder blindly points this issue out on a newbie map. It is likely that the newbie will listen and use a different slider velocity.
I don't want to cause a large discussion about this. Is peppy going to decide personally whether this is going to be allowed?
Kodora
kinda agree with you, TVO
Btw, i always forgot about this map
https://osu.ppy.sh/b/126010 (eXtreme) - this map uses a lot of unrankable sliders but it done in way where it perfectly fits the music. For example, 02:40:837 (1,2,3) - x3.00 sliders what plays really good. I asked some of my friends to play them and only few people did 100 here, but everyone agree that they not impossible or unreadable.
And a lot of x0.25 sliders what done as a good alternative for x0.50 to emphazire slowdowns on parts where they placed.
Btw, i always forgot about this map
https://osu.ppy.sh/b/126010 (eXtreme) - this map uses a lot of unrankable sliders but it done in way where it perfectly fits the music. For example, 02:40:837 (1,2,3) - x3.00 sliders what plays really good. I asked some of my friends to play them and only few people did 100 here, but everyone agree that they not impossible or unreadable.
And a lot of x0.25 sliders what done as a good alternative for x0.50 to emphazire slowdowns on parts where they placed.
uhm, peppy, you deleted all of my post where I was actually discussing the examples...
even the one with the new guideline proposition.
even the one with the new guideline proposition.
Kodora
Just one more example why we shouldn't focus on multiplier's numbers.
BARAKO - Otomegokoro x Kyokuchuuhatto -dandara shooting MIX- - 04:09:510 (1) - 370 bpm, x0.13 slider
Hashimoto Miyuki - Especially (Hard) - 01:41:146 (2) - 93 bpm, x0.50 slider
Both maps used same slider velocity - 1.40
Pretty easy to calculate that in fact x0.13 slider on BARAKO is faster than legit x0.50 slider in Especially.
As i said before, SV multipliers are just a numbers what may works very depends on different maps. Only real playability is the main important thing what modders should focus on - we dont need any numbers-related moderation.
BARAKO - Otomegokoro x Kyokuchuuhatto -dandara shooting MIX- - 04:09:510 (1) - 370 bpm, x0.13 slider
Hashimoto Miyuki - Especially (Hard) - 01:41:146 (2) - 93 bpm, x0.50 slider
Both maps used same slider velocity - 1.40
Pretty easy to calculate that in fact x0.13 slider on BARAKO is faster than legit x0.50 slider in Especially.
As i said before, SV multipliers are just a numbers what may works very depends on different maps. Only real playability is the main important thing what modders should focus on - we dont need any numbers-related moderation.
If people in charge understood they should focus on playability instead of numbers and theories you wouldn't be arguing this.
the first map have doubled bpm, so in reality it's a map at 185 bpm with x0.25 sliders, but the used of slow sliders is rightly done, so it's a good example in that ( bad flow in some parts though )Kodora wrote:
Just one more example why we shouldn't focus on multiplier's numbers.
BARAKO - Otomegokoro x Kyokuchuuhatto -dandara shooting MIX- - 04:09:510 (1) - 370 bpm, x0.13 slider
Hashimoto Miyuki - Especially (Hard) - 01:41:146 (2) - 93 bpm, x0.50 slider
Both maps used same slider velocity - 1.40
Pretty easy to calculate that in fact x0.13 slider on BARAKO is faster than legit x0.50 slider in Especially.
As i said before, SV multipliers are just a numbers what may works very depends on different maps. Only real playability is the main important thing what modders should focus on - we dont need any numbers-related moderation.
SPOILER
peppy, please read my post BEFORE DELETING THEM.
And not only short ones, but longer ones too, since I posted:
-the new guideline draft
-commented other uses of SV multipliers
-justified use of SV multipliers
-said how I used SV multipliers
and so in my posts. And I didn't started a fuss over anything. So please, let my mental sanity remain by not deleting my posts randomly and blindly.
And not only short ones, but longer ones too, since I posted:
-the new guideline draft
-commented other uses of SV multipliers
-justified use of SV multipliers
-said how I used SV multipliers
and so in my posts. And I didn't started a fuss over anything. So please, let my mental sanity remain by not deleting my posts randomly and blindly.
this rule does apply only to osu!Standard
Kodora
MAMI ZONE
Ganymede kamome mix
PF concerto No1 'Anti-Ares'
Tatsh - IMAGE -MATERIAL- <Version 0>
some examples of good usage in taiko mode :3
Ganymede kamome mix
PF concerto No1 'Anti-Ares'
Tatsh - IMAGE -MATERIAL- <Version 0>
some examples of good usage in taiko mode :3
Firce777 wrote:
MAMI ZONE
Ganymede kamome mix
PF concerto No1 'Anti-Ares'
Tatsh - IMAGE -MATERIAL- <Version 0>
some examples of good usage in taiko mode :3
Read.HakuNoKaemi wrote:
this rule does apply only to osu!Standard
People do focus on readability. That's the point.Wishy wrote:
If people in charge understood they should focus on playability instead of numbers and theories you wouldn't be arguing this.
Well, if the rule (in reality, guidelines) can be extended to Taiko and CtB, there are no problems, it's the same matter:
"Will the pattern be playable?" and that's to be understood via testplay by various mappers, players and so.
The use of it should be avoided in easier difficulties, though ( SV changes might not be readable for people who barely started* )
*though my examples where deemed readable and good flowing by people who didn't play ( just because it "flowed" with music )
"Will the pattern be playable?" and that's to be understood via testplay by various mappers, players and so.
The use of it should be avoided in easier difficulties, though ( SV changes might not be readable for people who barely started* )
*though my examples where deemed readable and good flowing by people who didn't play ( just because it "flowed" with music )
Kodora
Due to stuff what was mentiored by Ono i guess it can be perfectly usable in Taiko mode.
I guess whe shouldn't do exceptions from this rule for other modes.
I guess whe shouldn't do exceptions from this rule for other modes.
If something is not officially supported by the editor, it is not officially supported, simply put. This functionality is better suited as a feature request rather than a ranking criteria amendment.
Will be denying within 24 hours if no further substantiation is given as to why this should exist as a criteria amendment and not a feature request.
Will be denying within 24 hours if no further substantiation is given as to why this should exist as a criteria amendment and not a feature request.
Eph, if you read the thread, this actually WAS a feature request, but someone (like hmm, peppy ?) suggested to change the rules so editing .osu for certain things was permitted.
Actually, it's probably better, since touching the .osu is not something beginner mappers would do, but pro mapper probably will know how to do it.
Actually, it's probably better, since touching the .osu is not something beginner mappers would do, but pro mapper probably will know how to do it.
not going to make shortcuts in feature development something we compensate for by the ranking criteria - see hold sliders
excuse me? small comprehension questionEphemeral wrote:
not going to make shortcuts in feature development something we compensate for by the ranking criteria - see hold sliders
So you're saying this should be a rule change instead of a feature request (which it is currently)?
Kodora
Yes, this is was feature request to allow SV multipliers from osumania in osu standard. Moved here by woc2006 and reverted to rule change later according to Garven's suggestion:peppy wrote:
@peppy's edit: editing the .osu file is possible, but is against current ranking criteria. Therefore, sliders changed that was are UNRANKABLE at the moment. We either need to change that rule or the editor's possibilities
Current rules already allowes editing .osz for skin-related options and .osu-specific storyboards. Suggested wording will just add one more exception for this.Garven wrote:
Considering how infrequent this would be used, it would be better to amend the editing of osu files rule then continue this movement to allow going beyond the constriction in special cases.
In general, the current editor constriction is adequate for moat playable mapping. As long as such an amendment doesnt bring back hold sliders, I am fine with it.
Moreover, there is other kind of problem: with implimenting new osu!mania editor become possible to create x0.10-x10.0 sliders without editing .osz, but rules wasnt updated according to this. We need this discussion here.
Hold sliders problem was discussed here 2 pages earlier - p/2542798Ephemeral wrote:
not going to make shortcuts in feature development something we compensate for by the ranking criteria - see hold sliders
Just going to add that this rule change here supported not to bring back hold sliders, but for rational usage. For any abuse we have qualified members to pop/unrank map what will have it.
I second that.HakuNoKaemi wrote:
Actually, it's probably better, since touching the .osu is not something beginner mappers would do, but pro mapper probably will know how to do it.
It was arleady largely demonstrated that slower/faster velocity sliders and holding slders are in fact different (arleady posted in the past)Ephemeral wrote:
not going to make shortcuts in feature development something we compensate for by the ranking criteria - see hold sliders
i'm saying it should be a feature request foremost and is thus completely unsuited for discussion as a rule changeZarerion wrote:
excuse me? small comprehension questionEphemeral wrote:
not going to make shortcuts in feature development something we compensate for by the ranking criteria - see hold sliders
So you're saying this should be a rule change instead of a feature request (which it is currently)?
just saying that the current limit is set by current RC, that is, without the update of RC there's no reason to change the editor setting first > >
Please read the topic. You will know who actually directed it as a rule change, and that it, in fact, was a feature request ( first posts are full of "support" and so )Ephemeral wrote:
i'm saying it should be a feature request foremost and is thus completely unsuited for discussion as a rule change
i am seeing 0 reason as to why this should be anything beyond a feature request given the support for the functionality and the examples listed in the thread of sneaky implementations of this feature which have been done in an effective and non-intrusive manner
A few things to note before this gets denied.
Is this unrankable even though there are ranked versions? Should BATs be forcing mappers to change such things?
Policy is policy. Rules are rules. If this is not implemented in the editor, then BATs must assume it to be unrankable based on the wording of the criteria unless the criteria is changed to accommodate such a change. Maps are getting ranked right now with such unrankable things. This issue should be handled with some degree of haste. Some BATs have felt it acceptable either by being misinformed or otherwise to rank unrankable things and mappers have found purpose to do something that is not supported by the editor. Are we to make a stand about limiting mapper freedom until such a matter is resolved in whatever span of time this gets added to the editor? This thread should be taken evident and I find it not so unbelievable to state that this stance is not in favor by the majority.
If this functionality is planned for a future release, then for what good reason should we call it unrankable. You have already admitted that examples made in this thread are rankable despite the rules clearly saying they aren't. I think this goes beyond a feature request. This functionality should be included as part of the editor or the rules should be shifted. If the request is not going to be handled immediately then we should change the rules.
Since you can't change audio leadin in the editor anymore, does this mean it is unrankable? People who read the rules will assume it is.
I don't mind telling people their slider velocities are unrankable. I just wont have a good reason why. I am not a BAT who can decide when a rule can be broken and the wiki clearly states that rules are not up for interpretation, so I must not go by reasoning whether it should be broken, but by the law of the wiki, which tells me it cannot be broken. I am of course assuming the position of someone taking their values directly from the criteria as it is written. Fortunately most people don't care about the rules when they mod, but this is misleading being a rule.
That is my view on this situation.
Edit: Simplified my opinion and sharpened the focus.
Is this unrankable even though there are ranked versions? Should BATs be forcing mappers to change such things?
Policy is policy. Rules are rules. If this is not implemented in the editor, then BATs must assume it to be unrankable based on the wording of the criteria unless the criteria is changed to accommodate such a change. Maps are getting ranked right now with such unrankable things. This issue should be handled with some degree of haste. Some BATs have felt it acceptable either by being misinformed or otherwise to rank unrankable things and mappers have found purpose to do something that is not supported by the editor. Are we to make a stand about limiting mapper freedom until such a matter is resolved in whatever span of time this gets added to the editor? This thread should be taken evident and I find it not so unbelievable to state that this stance is not in favor by the majority.
If this functionality is planned for a future release, then for what good reason should we call it unrankable. You have already admitted that examples made in this thread are rankable despite the rules clearly saying they aren't. I think this goes beyond a feature request. This functionality should be included as part of the editor or the rules should be shifted. If the request is not going to be handled immediately then we should change the rules.
Why should there be a rule with a bunch of exceptions attached anyways? Noone really checks to see if the .osu has been modified and each time the editor is simplified another exception to this rule is made. It's treated like a guideline according to you. It should be a guideline IMO.Ephemeral wrote:
If provisions are not made within the editor to allow for various map settings, assume they are not rankable.
These can be assessed on a case by case basis and do not need individual justification within the ranking criteria.
Since you can't change audio leadin in the editor anymore, does this mean it is unrankable? People who read the rules will assume it is.
wiki wrote:
All rules are exactly that: RULES. They are NOT guidelines and may NOT be broken under ANY circumstance.
I don't mind telling people their slider velocities are unrankable. I just wont have a good reason why. I am not a BAT who can decide when a rule can be broken and the wiki clearly states that rules are not up for interpretation, so I must not go by reasoning whether it should be broken, but by the law of the wiki, which tells me it cannot be broken. I am of course assuming the position of someone taking their values directly from the criteria as it is written. Fortunately most people don't care about the rules when they mod, but this is misleading being a rule.
That is my view on this situation.
Edit: Simplified my opinion and sharpened the focus.
Kodora
So is adding one more exception will hurt, especially if it already have huge support?TheVileOne wrote:
You have already admitted that examples made in this thread are rankable despite the rules clearly saying they aren't. Why should we even have a rule that has tons of exceptions to it? The rule I am referring to is the editing the .osu rule, removal of which has been denied twice even though it's barely enforcable and noone checks if it's been modified. This "rule" has more exceptions than can be listed and more exceptions keep getting added. (You can't set audio leadin in the editor anymore. Does this mean that custom audio leadin is now unrankable? What about video offset? Changing an mp3's title? ) I thought rules are supposed to be exceptionless and not be up for discussion, and yet this rule seems to have lots of exceptions.
Thought it really would be better to have it directly in editor (like o!m mode have) instead of painful editing .osz but leave it as advanced mapping technique is nice idea too imo.
And what about using o!mania editor to achieve extra slider speeds?
what I am saying is that this will be denied based on the fact that it should be a feature request rather than an RC change, given that the end effect of this functionality (precision slider velocity settings) is widely considered by virtue of consensus to be an effective and reasonably useful feature. i would rather we support this feature with editor functionality than adding an exception that encourages people to edit the .osu files - which are prone to rapid change as per the development cycle.
as such, i'd much rather see this thread split into things the RC can address, such as when these precise slider velocities should be used, and when they should not. does that make sense?
tl;dr: going to deny because this is better suited as a feature, not as a shonky RC change that encourages third-party editing
as such, i'd much rather see this thread split into things the RC can address, such as when these precise slider velocities should be used, and when they should not. does that make sense?
tl;dr: going to deny because this is better suited as a feature, not as a shonky RC change that encourages third-party editing
okay, look, here's what we're going to do
because adding this as a feature will take a little time and i'm tired of no progress being made on this front, i am accepting this as a provisional rule - meaning that it will only apply until it is supported officially by the editor, but it is subject to one additional amendment:
because adding this as a feature will take a little time and i'm tired of no progress being made on this front, i am accepting this as a provisional rule - meaning that it will only apply until it is supported officially by the editor, but it is subject to one additional amendment:
Do not manually edit anything in an .osu file that cannot be changed through the Editor. The only exceptions are .osu-specific storyboards, slider velocity multipliers and skin-related options such as SliderBorder and SliderTrackOverride. If non-standard slider velocity multipliers are used, they must be announced in the beatmap description during the modding process.This is to permit a more critical and obvious view of the use of non-standard slider velocities in the leadup period before the feature is introduced properly.
Kodora wrote:
Awesome <3
Kodora wrote:
Awesome <3