sliders < 0.5x is a hold anyway. wait for hold notes to be implemented.
forum
[Rule Change] Slider Velocity multipliers usage. 2165w
posted
Total Posts
153
Kodora
Main problem of hold sliders is that they give drastic effect while playing (unexpected and counter-intuitive speed jump as i said above). If it done in way where they dont hurts while playing i guess it works fine (as example you can make progressive SV decreasing same as progressive SV raising). x0.5 is just a number, final speed & playability very depends to bpm, song and patterns what mapper used.peppy wrote: 73101g
sliders < 0.5x is a hold anyway. wait for hold notes to be implemented.
Unlike "hold note" where player needs to hold & wait slider gives absolutely different feelings while following sliderball (x0.25 and slower sliders can be done as enough long ones to follow sliderball instead of holding cursor in one point - this is different).
Thats why allowing < 0.5 is important.
I'm only chipping in my opinion here, but it's based on what I consider to be a rather large amount of experience on my part. A fast song will yield faster sliders as a matter of course and extremely slow SV leaves a ridiculously limited scope for patterns, which will always end up being scrunchy, self-overlapping and barely-moving messes. In this instance, the only way to create more motion is to juxtapose horrifically slow sliders with horrifically disproportionate jumps. It's not a good experience for me. Halving the speed already creates enough of a change in feel which actually relates to the music.pieguy1372 wrote: 5n6l
except we have a team called BATs who can identify "abuse" before the map gets ranked. if someone puts a 5.0x slider and it defies all sense, it'll be removed anywayD33d wrote: 1z2z1f
The current limitations also give good results and I'm also willing to bet that the amount of abuse would outweigh the occasional good application in a pretty horrible way. The last thing that this place needs is an "it's technically feasible, therefore I'm doing it no matter what" argument over SV. Halving and doubling the velocity is already pretty drastic.
that's your personal preference. You don't like really slow sliders, so they shouldn't be implemented? I think we can all see this makes no sense = =D33d wrote: 1z2z1f
Going by what peppy said, extreme slowdowns would be much more likely to succeed than extreme speedups, but aside from the sliderball's animation looking horrible, going too slow makes a map plod tediously. I always hate it when that happens, because it barely feels involving in the slightest. Having the sliders too fast is disastrous. What we have now is a good middleground between "too slow" and "too fast."
and before you say "but it's personal preference to put sliders > 2.0x or < 0.5x cause I know someone will try it, just look how many people ed this (+30 in the first 3 hrs...) the number of people who want this is really greater than the number of people who don't
Overly fast sliders become ridiculously uncomfortable to play and only fit intense songs. For a fast song, setting the SV correctly in the first place will allow for plenty of momentum at 1x, which would already become extremely fast at 2x--in such a case, I wouldn't even recommend more than 1.5x increases for anything which gets close to 200BPM. Slowing things down to half-speed would make things slow enough without compromising the overall feel of the song, while an actual slowdown in the song's tempo would make SV multipliers irrelevant--a tempo change would be used, which would slow down the default SV anyway.
Moreover, I don't consider it unreasonable to expect that such an implementation would be abused enough for it to be removed at some point. That's already happened after far too much farting around. There's quite enough flexibility with the current settings and simply changing the flow of a section can have a massive effect on how the section feels in relation to the music. If I were a BAT, then I'd rather not want to add even more obscene SV abuse to my daily shit-list, so being preventive in this case would save a lot of headaches.
As peppy also said, extremely slow sliders play as holds. They carry no real impetus and defeat the purpose of a "slider." To quote Charles out of context, they're a "waiting game" and I've never seen them used in a fun way, ever. As for the sliderball looking like arse, its animation doesn't have that many frames--at extremely slow speeds, the animation becomes jerky and looks very goofy. It would probably continue to look nasty at <0.5x if more frames were added, unless somebody really wants to make loads of subtle shading changes to the ball itself.
Also, the amount of ers doesn't necessarily imply that everybody wants it--it just shows that lots of people want it. You don't know how many people would detest this without them expressing their disapproval and a good many of them probably don't want to become involved in any arguments over this anyway.
To sum up my opinion on this: At a given tempo, extreme changes in speed are jarring and, assuming that the default setting feels good, extreme changes will not feel good regardless of how gradually they're introduced. The current restrictions are hardly limiting to one's creativity, because there are loads of other ways to create intensity and calmness without ever touching the multiplier. If the global SV can't be tuned to work with faster and slower sections, then it was probably set incorrectly to begin with.
I'm only chipping in my opinion here, but it's based on what I consider to be a rather large amount of experience on my part.so all the people who do this, including BATs and experienced mappers, don't have as much experience as you. ok
A fast song will yield faster sliders as a matter of course and extremely slow SV leaves a ridiculously limited scope for patterns, which will always end up being scrunchy, self-overlapping and barely-moving messes. In this instance, the only way to create more motion is to juxtapose horrifically slow sliders with horrifically disproportionate jumps. It's not a good experience for me. Halving the speed already creates enough of a change in feel which actually relates to the music.I have no idea what you're even talking about, but I'll try anyway
A fast song will yield faster sliders as a matter of course and extremely slow SV leaves a ridiculously limited scope for patterns, which will always end up being scrunchy, self-overlapping and barely-moving messes.your opinion, and I think we all know using "always" in relation to mapping doesn't work
In this instance, the only way to create more motion is to juxtapose horrifically slow sliders with horrifically disproportionate jumps.people use slow sliders to create less motion cause having too much motion doesn't fit
Halving the speed already creates enough of a change in feel which actually relates to the music.ok, but in special cases sliders <0.5x work well and feel really good ~
Overly fast sliders become ridiculously uncomfortable to play and only fit intense songs. For a fast song, setting the SV correctly in the first place will allow for plenty of momentum at 1x, which would already become extremely fast at 2x--in such a case, I wouldn't even recommend more than 1.5x increases for anything which gets close to 200BPM.on certain occasions a slider needs to have a speed > 2.0x. I doubt people are gonna make a whole 3.0x section. hey at least it also allows the possibility if someone does it well
in other words
me wrote: 4q6448
but if we can do even better removing the limitations, why do you wanna disallow that? = =
Moreover, I don't consider it unreasonable to expect that such an implementation would be abused enough for it to be removed at some point. That's already happened after far too much farting around.maybe it will and maybe it won't. it might happen but imo people are most likely going to use it well. in other words
me wrote: 4q6448
but if we can do even better removing the limitations, why do you wanna disallow that? = =
If I were a BAT, then I'd rather not want to add even more obscene SV abuse to my daily shit-list, so being preventive in this case would save a lot of headaches.and also prevent a lot of amazing things from happening
Also, the amount of ers doesn't necessarily imply that everybody wants it--it just shows that lots of people want it. You don't know how many people would detest this without them expressing their disapproval and a good many of them probably don't want to become involved in any arguments over this anyway.I never said everyone wants it. just, the fact that 23984739284 people posted "" and you two are the only ones who are really against it, that really says something imo
To sum up my opinion on this: At a given tempo, extreme changes in speed are jarring and, assuming that the default setting feels good, extreme changes will not feel good regardless of how gradually they're introduced. The current restrictions are hardly limiting to one's creativity, because there are loads of other ways to create intensity and calmness without ever touching the multiplier. If the global SV can't be tuned to work with faster and slower sections, then it was probably set incorrectly to begin with.
tl;dr: everything in your post can be refuted with just 2 sentencesme wrote: 4q6448
you're completely missing the point. everyone agrees that allowing higher multipliers will be EVEN BETTER than leaving it the way it is. we can do well staying within limitations, but if we can do even better removing the limitations, why do you wanna disallow that? = =
I'm done here until someone refutes this ^me wrote: 4q6448
everyone agrees that allowing higher multipliers will be EVEN BETTER than leaving it the way it is. we can do well staying within limitations, but if we can do even better removing the limitations, why do you wanna disallow that? = =
last up
IMO, people will sometimes want to make a really slow, holding feeling without "no motion". In other words, sometimes they want just a very slow motion instead of none at all. That's why I think sliders < 0.5 is valid and separate from "hold notes" = =peppy wrote: 73101g
sliders < 0.5x is a hold anyway. wait for hold notes to be implemented.
This is not true when the slider is long.peppy wrote: 73101g
sliders < 0.5x is a hold anyway. wait for hold notes to be implemented.
@D33d: You are like, assuming just because you yourself wouldn't like a such sliders because of your personal opinion, it#s automatically bad.
Read my previous post. How would you define when it is "abused"? Is it abused the moment YOU as an INDIVIDUAL and a SUBJECTIVE opinion cannot enjoy it anymore?
You see, the essence of osu! is that everyone can play and map whichever song HOWEVER they like. As long as it is rhythmically correct, whether a map is good or bad is entirely subjective. Whether a slider is fun or not depends on the player.
Ever considered that other people made other experiences? That others might consider 0.5x to not have the effect they want?D33d wrote: 1z2z1f
It's not a good experience for me. Halving the speed already creates enough of a change in feel which actually relates to the music.
Again, this is simply your own preference.D33d wrote: 1z2z1f
Overly fast sliders become ridiculously uncomfortable to play and only fit intense songs. [...] Slowing things down to half-speed would make things slow enough without compromising the overall feel of the song
They do not. A slider will always be that, a slider, and will ALWAYS have the effect of something moving. Hold Notes would need to be used entirely differently, if ever implemented.D33d wrote: 1z2z1f
As peppy also said, extremely slow sliders play as holds.
So what does the Feature Request, subforum, where this thread originally was, exist for, then, if the opinion of >30 sup-stars on the first day doesn't count? Do we just ignore the ~7 pages of people who agree with the OP because MAYBE there MIGHT be some other people who think differently, if they can't even be arsed to the discussion? They cannot be against this all that much if it's too stressful to explain why they disagree, can they? You are assuming things one after.D33d wrote: 1z2z1f
Also, the amount of ers doesn't necessarily imply that everybody wants it--it just shows that lots of people want it. You don't know how many people would detest this without them expressing their disapproval and a good many of them probably don't want to become involved in any arguments over this anyway.
why not? Why wouldn't they feel good? I've played some that play really well, just because you think differently doesn't make your opinion a fact.D33d wrote: 1z2z1f
At a given tempo, extreme changes in speed are jarring and, assuming that the default setting feels good, extreme changes will not feel good regardless of how gradually they're introduced.
Basically you are just assuming you can project your opinion, that lower or higher SV than currently possible, does not feel well when playing, on everyone else, without actually providing reasons as to why it would play bad. What makes a 0.4x Slider worse than a 0.6x one?
Just let the mapper interpret the song the way they want. ffs
Would it really harm anyone to implement this? <_<
By the way, D33d: Sorry for ripping your post apart like that, the same way pieguy did. We are not trying to offend you or anything. Please try to keep calm about this and not be biased.
Mapping need less rules anyway. Just make a rule "The map has to be rhythmically correct, i.e. no 1/16 when there is only 1/1." and let the mappers do their goddamn thing. Honestly now.
all this text is completely pointless. these threads should only have beatmaps posted to them, with examples of where did works or not. please do not post any more walls of text, but only examples of where this does/doesn't work. i'll do my part and delete any post which isn't either a) a map or b) a post about a previously posted map discussing whether it works well or not.
ok
https://osu-ppy-sh.tvgratuite.org/s/79449 5.0x slider at the end
either way, I'd be fine with just allowing changing it through .osu instead of putting it in the editor
https://osu-ppy-sh.tvgratuite.org/s/79449 5.0x slider at the end
either way, I'd be fine with just allowing changing it through .osu instead of putting it in the editor
https://osu-ppy-sh.tvgratuite.org/b/265413 [Blue Tear]
01:59:979 (5) -
fits the song, and by stacking notes above it I stop player's movement so they have the possibilty to read and understand the slider. However, whether it is fun is a question every player has to answer for himself.
01:59:979 (5) -
fits the song, and by stacking notes above it I stop player's movement so they have the possibilty to read and understand the slider. However, whether it is fun is a question every player has to answer for himself.
Kodora
Other examples what was not discussed yet:
https://osu-ppy-sh.tvgratuite.org/b/98451 - going to post this because noone discussed ending part here (10:44:207 (1)). Last slider gives "feeling of ending" what based on this calm note, its enough long & fast to follow it, and also enough intuitive to not make sliderbreak here. Also 00:12:303 (4) - this slider gives feeling of "something what will come", gives atmosphere of beginning of great challenge.
https://osu-ppy-sh.tvgratuite.org/b/98451 - going to post this because noone discussed ending part here (10:44:207 (1)). Last slider gives "feeling of ending" what based on this calm note, its enough long & fast to follow it, and also enough intuitive to not make sliderbreak here. Also 00:12:303 (4) - this slider gives feeling of "something what will come", gives atmosphere of beginning of great challenge.
https://osu-ppy-sh.tvgratuite.org/s/60722
I forgot this.
00:04:847 (1) -
01:23:922 (1) - THIS IS JUST COOL AS FARK (especially with the SB and the kiai flashes)
I forgot this.
00:04:847 (1) -
01:23:922 (1) - THIS IS JUST COOL AS FARK (especially with the SB and the kiai flashes)
Kodora
It was actually, but moved here.Oyatsu wrote: 333v4b
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.tvgratuite.org/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: z6c2f
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.tvgratuite.org/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.tvgratuite.org/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: z6c2f
https://osu-ppy-sh.tvgratuite.org/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.tvgratuite.org/p/contestresults?e=100
https://osu-ppy-sh.tvgratuite.org/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 . 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 .
I'm taking the liberty of having a look at these examples, but the 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 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: 6z4f1h
[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 . 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 .
I'm taking the liberty of having a look at these examples, but the 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 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 ing 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 ing 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 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: 1z2z1f
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: 5a4a5f
Don't slander the mapper just because it doesn't fit your taste.
1) Cry for Eternity - https://osu-ppy-sh.tvgratuite.org/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.tvgratuite.org/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: 2w5u1t
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: 3w455y
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 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 ers 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 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 ers 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.
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: z6c2f
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 multipliers
A 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 multipliers
While 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.
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: 331p4a
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: p102h
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.
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?
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.tvgratuite.org/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.tvgratuite.org/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.
Kodora
Just one more example why we shouldn't focus on multiplier's numbers.
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.
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.
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: 1m1h4o
Just one more example why we shouldn't focus on multiplier's numbers.
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.
Kodora
Tatsh - IMAGE -MATERIAL- <Version 0>
some examples of good usage in taiko mode :3
some examples of good usage in taiko mode :3
Firce777 wrote: 1bq47
Tatsh - IMAGE -MATERIAL- <Version 0>
some examples of good usage in taiko mode :3
Read.HakuNoKaemi wrote: z6c2f
this rule does apply only to osu!Standard
People do focus on readability. That's the point.Wishy wrote: 205e2e
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 ed by the editor, it is not officially ed, 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.
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: 73101g
@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: 3w455y
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: b493z
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 ed not to bring back hold sliders, but for rational usage. For any abuse we have qualified to pop/unrank map what will have it.
I second that.HakuNoKaemi wrote: z6c2f
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.
i'm saying it should be a feature request foremost and is thus completely unsuited for discussion as a rule changeZarerion wrote: 6z4f1h
excuse me? small comprehension questionEphemeral wrote: b493z
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)?
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 ed 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 itted 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 ed 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 itted 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: b493z
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: 3c1k6d
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 ?TheVileOne wrote: p102h
You have already itted 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 ing 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 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 ed 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 ed 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.