support (I have no votes )
support~Satellite wrote:
Fear wrote:
supportsupport~scanter wrote:
support.
I already linked example for approved map with x0.13 slider where it works wellBeatofIke wrote:
I honestly found 0.25x to 5x slider multiplier reasonable in general. I think going under 0.25x and over 5x would be overdoing it imo.
Usually very long slow sliders have a lot of sliderticks what helps survive a lot (look at lesjuh's approved map with x0.13 and x0.20 slider) Extremely long unneeded sliders will be just modded out.BeatofIke wrote:
I'm still in doubt with the lower slider velocity part because of the drain rate (and when playing with HR and higher OD), as you could be performing well during gameplay only to fail at the drain section.
Just same limit as in o!m editor would be enough imo.Wishy wrote:
Changing the limit from the actual one to x0.00000000001 to x99999999999999999999999 would be nice. Not like you will get any map ranked with x999999999 SV.
rrtyui for best 5.0x 2013rrtyui wrote:
support (I have no votes )
How to express that you're supporting the request then if you don't have stars?peppy wrote:
Please don't post "support" replies. I have disabled the ability to do this.
That's how you support properlyZarerion wrote:
I fully support this. As seen in some maps, slow or high velocity sliders can work insanely well and flow with the music. They can build up suspense or calm the player down. They are a mapping technique that should not be prohibited, just like any other. Keep in mind that sliderticks can be used to make them readable, and if they really are not, modders and BAT will point them out.
supportThat's how you not I guess?
But editing osu! files is unrankable, isnt it?peppy wrote:
As for changing these limitations: I see no reason to do this in the editor. If you really feel the need, then edit the osu! file. The current limitations are fine.
deadbeat wrote:
and before you say something vague like variety, i'd like examples of this being used well
Those maps are not extremely old, and playability of them was confirmed by at least 3 BATs. I guess a lot of players can agree that it plays well too.Kodora wrote:
2)We already have approved maps what uses different SV multiplier.
http://osu.ppy.sh/b/98451 - this map uses x0.13 and x0.20 sliders (00:12:303 (4) - and 10:44:207 (1) - ). They plays well, fits the music and works enough intuitive
http://osu.ppy.sh/b/92051 - this map uses x2.40 slider (08:03:290 (1,2,1,2,1,2,1,2) - ) The progressive increasing of slider velocity makes it plays intuitive and it fits the music as well too.
That's not the point. Why does the range have to be increased in order for you (anyone) to be creative? 0.5x to 2.00x is great. Besides, only a minimal amount of people understand what abuse really is (as history proves). Also,Kodora wrote:
Why it should be unrankable if it can be done well & creative?
This has been the wrong mindset and we've been telling you this. Each map is its independent entity; one's allowance does not imply another. Additionally, these should have been caught before they were ranked, and can only be blamed on the inability (or misjudgment) of some.Kodora wrote:
2)We already have approved maps what uses different SV multiplier.
Isnt point at all. Why only x0.50-x2.00 then?those wrote:
That's not the point. Why does the range have to be increased in order for you (anyone) to be creative? 0.5x to 2.00x is great
We have qualified members to judge map's quality (including ranking & unranking) and a lot of modders to prevent any abuse usage for any avaliable point.those wrote:
Besides, only a minimal amount of people understand what abuse really is (as history proves).
I linked this approved maps as example of sliders what already breaks current slider velocity multiplier and was done well, plays good, intuitive, follows music and playability of them was confirmed by at least 3 BATs and a lot of players (example of playability). I linked them not to discuss how fair was this approving, dont missunderstand me please.those wrote:
This has been the wrong mindset and we've been telling you this. Each map is its independent entity; one's allowance does not imply another. Additionally, these should have been caught before they were ranked, and can only be blamed on the inability (or misjudgment) of some.
I gived maps for example how it can be used in creative way over current limit. I dont see any reason to keep it limited.D33d wrote:
I really don't think that there's any need for this. There's enough scope for creativity and pacing with .5x and 2x alone, not to mention everything in between.
Main point - it can be done well and intuitive. If it plays bad it just will be modded out.D33d wrote:
need to be changed so drastically.
There are a lot of things what was provided before (stack leniency 0, CS0, 8-10, volume sections 0%, spinner-rule about 2000 bonus etc) but what was removed or changed for specified reasons. And a lot of absolutely new things what was added just by people's requests. As you can see, a lot of people supporting changing current slider velocity multiplier because allowing more huge one have very big potential of creativity usage - enough fair reason i guess.those wrote:
The reason why 0.5x to 2.0x is used is because that is what's provided.
I just showed a simple examples of potential usage of it what people already like, thats all.those wrote:
..and I explained why that's not an argument. Stop bringing up specific maps in support of this because there's no support in that.
Wait whats wrong with sliderballs wits sections slower than x0.5? o_Opeppy wrote:
I would consider allowing less than 0.5x if the slider ball is first converted into a proper 3d object so the animation doesn't look like balls.
Its not always crazy, it can be done well if it fits the music. For example, as i linked in my first post, progressive SV raising technique - player can understand that next slider goest faster and can aim it well (map for example - http://osu.ppy.sh/b/92051 - 08:03:290 (1,2,1,2,1,2,1,2)).peppy wrote:
Above 2x is just crazy talk.
What about Taiko? I wanted to ask this some time ago as well. Sometimes there are notes which require a higher SV multiplier than x2.00 due to overlapping issues. Certain songs allow to have fast appearance of finisher, sliders or spinners, but the editor doesn't. So it becomes problematic once a song reach the +200 BPM because then, the x2.00 or x1.50 has no usage anymore due to bad overlapping which could be fixed by x4.00 multiplier. I doubt there is a skinning restriction in Taiko, since there are no 3D effects, or? Also it would give us one of our -okay, I call it now carefully- gimmicks back, which TNT is using often for example, but not unreasonable. After all, we have only one axis, and having one more restriction in a one axis game is... well, less possibilities in mapping. If something crazy should happen, the Taiko-BAT is the first one on the front to stop this.peppy wrote:
I would consider allowing less than 0.5x if the slider ball is first converted into a proper 3d object so the animation doesn't look like balls. Likely not going to happen due to skinning restrictions, though. Above 2x is just crazy talk.
You simply do not understand. You can use "progressive SV raising technique" while still staying within 2.0x slider velocity.Kodora wrote:
Its not always crazy, it can be done well if it fits the music. For example, as i linked in my first post, progressive SV raising technique - player can understand that next slider goest faster and can aim it well (map for example - http://osu.ppy.sh/b/92051 - 08:03:290 (1,2,1,2,1,2,1,2)).peppy wrote:
Above 2x is just crazy talk.
Its not onliest mapping technique what may works well with sliders faster than x2.00 but i hope it will be good example.
It cant be achieved using current limitations.those wrote:
That's not the point. The point is what you want achieved can already be achieved with the current limitations. Anything besides this is extraneous.
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.Kodora wrote:
Main point - it can be done well and intuitive. If it plays bad it just will be modded out.
But new limitations can give much more better result if they will be done rational. Its absolutely new prospects.D33d wrote:
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.
If it done rational it wont be drastic. Also, a lot of people like huge speedchange nowadays (if it needs i will give links to maps what used huge speedchanges and what have a lot of fauvorites, positive feedback from players, positive votes etc etc etc).D33d wrote:
Halving and doubling the velocity is already pretty drastic.
I dont know what's wrong with sliderball's animation. Maybe its just me but it also looks okay as for me (https://osu.ppy.sh/s/29705 - for example this map, it have x0.13 and x0.20 sliders but they looks as usual here)D33d wrote:
but aside from the sliderball's animation looking horrible
those, why you consider this in such a negative way? Its not a mythical "war with system", its just a reasonable suggestion to give new prospects for mapping, to give new ways of creativity. If it can be done well why it shouldnt be rankable? If current system can be improved, then why not do it? If potential can be increased, then why not?those wrote:
Once again, map reference doesn't do a thing.
You only think it can't be done because you see a 240% ratio. As a matter of fact, the maximum slider velocity could have been 2.0x and the progression could have been just as great. The reason why you can't see this is because you (not only you) have forced yourself to try to break the system instead of using what you're given to fuller potential.
except we're saying it couldn't have been just as great. read the thread plzthose wrote:
You only think it can't be done because you see a 240% ratio. As a matter of fact, the maximum slider velocity could have been 2.0x and the progression could have been just as great.
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? = =those wrote:
The reason why you can't see this is because you (not only you) have forced yourself to try to break the system instead of using what you're given to fuller potential.
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:
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:
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."
this for god sakes. if you wanna use this trick it becomes impossible to make an "effective" 0.5x section, just that. also I had a map that had a 0.25x slider immediately followed by a 2.0x slider and it was perfect (before anyone complains, dl the map and try to make something better plz, yeah I'm that confident)Kodora wrote:
Some resolving what people usually suggest: double basic SV and half SV in all inherited sections. But it not always works. Biggest problem - it makes impossible to make slowdown parts (what also can be far, far away from speedup parts and will never confuse player). As Charles said before, bigger limit would work better in this case.
what's the problem with hold sliders? we all agreed they played epic way back when till they were apparently unrankable. just putting a 0.25x green section seems fine enough, just no one does it cause we got used to not having themGarven wrote:
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.
Very good solution imoGarven 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.
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 multiplier and skin-related options such as SliderBorder and SliderTrackOverride.And put x0.5-x2.00 to guidelines.
of course it would be Insane-only... SV changes are like never used in any lowdiffs in the first placeStefan wrote:
This would be a only-Insane technique since things like that are used for being really complicated. I'd also say that Hold sliders should not be made on this way then but I see a lot of potential if we allow to use <0.5x / >2.0x SV per green Lines. I see good things coming with that but also bad ones. Cannot result about this.
Of course. Any spedchanges usage on easiest diffs isnt recommended at all.Stefan wrote:
This would be a only-Insane technique since things like that are used for being really complicated.
Little point about hold sliders. "Hold slider" in fact is uncommon usage of speedchanges (extreme jump from normal/fast slider to very slow one what definitely cant be noticed while playing, plays weird and where music doesnt requires it). This is just kind of abuse what obviously will be pointed out by modders and BATs while modding/ranking process. However, i must say that abuse usage can be done even with current multiplier, but i doubt that map what uses it will be ranked.Stefan wrote:
I'd also say that Hold sliders should not be made on this way then but I see a lot of potential if we allow to use <0.5x / >2.0x SV per green Lines. I see good things coming with that but also bad ones. Cannot result about this.
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:
sliders < 0.5x is a hold anyway. wait for hold notes to be implemented.
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:
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:
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:
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 supported 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
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 support 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
me wrote:
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:
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 supporters 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 "support" 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:
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:
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? = =
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:
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:
sliders < 0.5x is a hold anyway. wait for hold notes to be implemented.
Ever considered that other people made other experiences? That others might consider 0.5x to not have the effect they want?D33d wrote:
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:
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:
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 join 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:
Also, the amount of supporters 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:
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.
It was actually, but moved here.Oyatsu wrote:
I think this post should at Feature Request. Why it here? lol
I did.HakuNoKaemi wrote:
i didn't post an example
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
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]
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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
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)?