I dont know about you guys, but for me it looks like both rules are attacking different scenarios
forum
[Rule] Slider anchors/nodes...manipulate slider speeds
posted
Total Posts
108
Manipulating slider speeds to the point it's totally cramped means the path won't be readable. I never saw, for example, a slider that's so much slowed using nodes, that is actually at least doable or even readable.
So this over-case is already covered by the other rule.
So this over-case is already covered by the other rule.
Topic Starter
Sakura Hana wrote:
I dont know about you guys, but for me it looks like both rules are attacking different scenarios
if we put something about AIMod in the 2nd rule, it should be plenty.Sakura Hana wrote:
Crumpled sliders are not unrankable as they are, more like making them waaaaay too crumpled makes them unrankable because it becomes extremely slow and is a way around the slider speed limit that prevents hold sliders, as the rule says AIMod will catch any slider of these, so if AIMod says nothing, it's probably ok
They're both talking about unacceptable sliders. I'm not 100% on what is not rankable, and that to me is a problem, since the only thing that should be unrankable would be a "hold slider" effect, which is also impossible to follow since it moves in such a way that is impossible to read from start to end.
But the other problem with that is that it's a simple little slider that barely moves and you don't even have to move at all to get a 300 on it. Why is this so unrankable? because it's bad 90% of the time? I feel the same way with 1/4 repeating sliders. they play identically.
precisely an hold slider using manipulation of Slider Speed, is totally cramped and so unrankable.
Differently combining SV multiplier, with slider anchors/nodes is actually rankable ( you can obtain x0.75 with a finely zigzaged slider and a 0.5x section, x0.38 ) and "Nuked the .osu editing rule." means you can edit the .osu to obtain even x0.01 of SVM , and as so Hold Sliders.
We're waiting Hold Notes(Circles and Slider) mm.
Differently combining SV multiplier, with slider anchors/nodes is actually rankable ( you can obtain x0.75 with a finely zigzaged slider and a 0.5x section, x0.38 ) and "Nuked the .osu editing rule." means you can edit the .osu to obtain even x0.01 of SVM , and as so Hold Sliders.
We're waiting Hold Notes(Circles and Slider) mm.
No you can't. Something went wrong if there's no rule stopping these.HakuNoKaemi wrote:
"Nuked the .osu editing rule." means you can edit the .osu to obtain even x0.01 of SVM , and as so Hold Sliders.
Plus there's a bug when the SV becomes amazingly slow so don't do it.
From of the "nuke .osu editing rule" thread. "Consensus seems to be that if this causes issues, those issues are what we should be legislating against." But if using slow SVMs causes a bug then it should be obvious that this isn't acceptable
Topic Starter
Does everything need to be explicitly stated in the rules? Can't we just call the rules lawyer who says that 0.01 SV is rankable an idiot and nuke his map?mm201 wrote:
No you can't. Something went wrong if there's no rule stopping these.HakuNoKaemi wrote:
"Nuked the .osu editing rule." means you can edit the .osu to obtain even x0.01 of SVM , and as so Hold Sliders.
Plus there's a bug when the SV becomes amazingly slow so don't do it.
I mean I can think up many ways where 0.25x SV or 4.35x SV would be needed, for example, in a compilation map. All the maps will have already been ranked, so you know it's rankable...
The reasoning for getting rid of the osu edit rule and leaving nothing stopping the CS 1 and unrankable stack leniency was because there's no easy way to say it without being a stupid rule, and it's common sense. AIBat/AIMod should catch these errors, and osu forcefully fixes any game data errors on save (which it really shouldn't).
Except in compilation maps what changes is the BPM not the SV multiplier.
Topic Starter
and the tick rate.
It's quite possible that one of the maps uses something like 1.4 SV x0.5 inherits and another one 1.6 x2Sakura Hana wrote:
Except in compilation maps what changes is the BPM not the SV multiplier.
That would require a larger range of SVs for the compilation
I didn't know that fact, anyway there are low-bpm low-SV maps, so that would equal that a likely x0.1-x0.5 won't cause bugs.
If you limit the usable SVMs to x0.1-x4.0 and set a rule that using less or more will cause bugs.
Rules that prevent bugs are the first you should do ( not so many peoples know it too )
If you limit the usable SVMs to x0.1-x4.0 and set a rule that using less or more will cause bugs.
Rules that prevent bugs are the first you should do ( not so many peoples know it too )
WAT. Both sv and bpm are changedSakura Hana wrote:
Except in compilation maps what changes is the BPM not the SV multiplier.
If you're doing it right, then this in most cases.Natteke wrote:
WAT. Both sv and bpm are changedSakura Hana wrote:
Except in compilation maps what changes is the BPM not the SV multiplier.
On another note, I agree with this:
Does everything need to be explicitly stated in the rules? Can't we just call the rules lawyer who says that 0.01 SV is rankable an idiot and nuke his map?
Im really starting to think y'all are too concerned about the trivial matters
Let's just say don't let the slider speed with multipliers applied drop below 0.2x.
Works for me. ;Pmm201 wrote:
Let's just say don't let the slider speed with multipliers applied drop below 0.2x.
same hereEkaru wrote:
Works for me. ;Pmm201 wrote:
Let's just say don't let the slider speed with multipliers applied drop below 0.2x.
Topic Starter
Yes, but I really don't want to make that a rule.
When do sliders glitch? At what BPM * velocity * multiplier do they not work? What glitches?
When do sliders glitch? At what BPM * velocity * multiplier do they not work? What glitches?
Is that important?ziin wrote:
When do sliders glitch? At what BPM * velocity * multiplier do they not work? What glitches?
The point is that not doing stupid things with sliders in the first place means that one would never have to worry about breaking them. Ziin, stop overthinking things.
I would put a note at the end of the guildlines say "These are not an exhaustive list of guildlines, MAT/BAT have the final say as to what gets bubbled/ranked, if you have a problem with a decision, discuss it with the person or find someone else." That would save use from all the trivial matters that get discussed.
I want to know to...
What BPM*SV*Multiplier do you need to make the sliders glitch?
(It's important, you can actually make some sensed rule like this, as you will prevent bugs)
extending settable SVM from x0.5-x2 to x0.1-x5 seems good
What BPM*SV*Multiplier do you need to make the sliders glitch?
(It's important, you can actually make some sensed rule like this, as you will prevent bugs)
extending settable SVM from x0.5-x2 to x0.1-x5 seems good
Topic Starter
Well, yes.ouranhshc wrote:
Is that important?ziin wrote:
When do sliders glitch? At what BPM * velocity * multiplier do they not work? What glitches?
The whole reason there are lower limits is because sliders start glitching. The function for the actual slider velocity (the rate that the slider ball moves) is based on the BPM, SV, and SV Multiplier. If we put some arbitrary limit on one, then the glitch isn't actually prevented.
I think 0.5x and 2.0x is good enough for anybody, with the understanding that values over or under this limit are acceptable in certain cases. Most of the good mappers know how to use notepad anyway, and if you don't know how to use notepad, you can pretty easily ask for help, or someone will give it.
If we extend it though it needs to be symmetrical, so 0.2x-5x, or 0.25x and 4x. Not that I'm advocating extending it in the actual editor.
This is a legal slider with bpm 15, SV 0.5, SVM 0.5x, Tick rate 4.
Do you know any songs that actually use 15 bpm?
nope, but if the glitch use even lower than 15 x 0.5 x 0.5 ( 3.75 ) than it's really rare, as so there's no need of an anti-glitch rule. As I thought, glitch is the tick rates too.
So a guideline limiting usable SVs it's better
so: now you can do a marathon using legal SVs that use SVs:
0,5-2,0 or 1-4 and so
extending it to 0.2x-5x seems a good idea as you will have the ability to use
0.2-5.0, 0.4-10.0 and so,permitting all marathons
So a guideline limiting usable SVs it's better
so: now you can do a marathon using legal SVs that use SVs:
0,5-2,0 or 1-4 and so
extending it to 0.2x-5x seems a good idea as you will have the ability to use
0.2-5.0, 0.4-10.0 and so,permitting all marathons
Here's an idea: do whatever you want to the slider velocity until it breaks. If it breaks, then it's a sure sign that you're doing something wrongly. Fix the problem by using sliders which actually make sense and are fun to play. If ziin's example happens in a map, then any competent modder's response would be, "Whoa there buddy, you need to fix this."
This is far beyond the original point of the thread anyway, which is about crushing sliders into oblivion. Let's just agree that the easiest way to approach broken sliders is to deal with them when they happen, okay?
This is far beyond the original point of the thread anyway, which is about crushing sliders into oblivion. Let's just agree that the easiest way to approach broken sliders is to deal with them when they happen, okay?
I might know why: the ticks become so near the graphic card glitch while drawing them.
Anyway, rules are better used to prevent bugs.
It only happed with Tick Rate 4 when BPM*SV*SVM < 20 and it happens because of some kind of internal variables, as it happened only coming down. It's something like a random glitch too, as redoing it made me obtain different results.
No need for a rule, neither banning SV-edited velocities as:
-No one, no one use 4 Slider Tick 4
-No one will want to use less than less of SV
-So there's no point in banning them and saying "isn't logical they're banned...?"
So, Hold Sliders are usable
Anyway, rules are better used to prevent bugs.
It only happed with Tick Rate 4 when BPM*SV*SVM < 20 and it happens because of some kind of internal variables, as it happened only coming down. It's something like a random glitch too, as redoing it made me obtain different results.
No need for a rule, neither banning SV-edited velocities as:
-No one, no one use 4 Slider Tick 4
-No one will want to use less than less of SV
-So there's no point in banning them and saying "isn't logical they're banned...?"
So, Hold Sliders are usable
You know what i find funny, how this thread went into talking about the 0.5x ~ 2x slider speed limits instead of crumpled sliders.
Well, it's about manipulating slider speeds...
The rule we were discussing is deletable, completely
The rule we were discussing is deletable, completely
If the spacing between ticks is less than 10 osupixels, it may glitch.
10 osupixels?
2 grid 4 and half?
from what I've seen it's like it'll happen easily, if you pass from a glitched speed to a gliched speed, but... yeah, the distance between ticks centers was like 2 grid 4 or less(not tick borders)
Using a Tick 4 in a slow song doesn't happen that easily, actually...
2 grid 4 and half?
from what I've seen it's like it'll happen easily, if you pass from a glitched speed to a gliched speed, but... yeah, the distance between ticks centers was like 2 grid 4 or less(not tick borders)
Using a Tick 4 in a slow song doesn't happen that easily, actually...
Topic Starter
by glitch, you mean stack the ticks improperly or give up on putting in ticks halfway through?mm201 wrote:
If the spacing between ticks is less than 10 osupixels, it may glitch.
If it's stacking improperly this is a bug that should theoretically be 36/51 osupixels, as that's the size of the default slidertick (or just fix the bug, as custom sliderticks, while stupid, could be bigger than 36x36).
it's when tick centers are 10 osupixel near, so it's when ticks overlap by more than 26/41 pixels from 36/51, so about 72-80%. But it happens randomly. (I tested it for some time) and for the second half there weren't glitches ( seeing a literal white line formed by ticks and all of them sounded )
It also depends on how the slider is broken up into small lines and is complicated. It happens more often with linear sliders.
I'd like to backport the osu!stream slider code which is a million times better and doesn't have such a bug but that might be a ways off.
The bug causes rebounds' times to become misplaced and is really odd.
Sliders look dumb when their ticks are that close together anyway.
I'd like to backport the osu!stream slider code which is a million times better and doesn't have such a bug but that might be a ways off.
The bug causes rebounds' times to become misplaced and is really odd.
Sliders look dumb when their ticks are that close together anyway.
The discussion ended with a general agreement on deleting the rule because of it being included in the other slider rule...
SPOILER
you will port hold circles too?
o!s style holds will be coming whenever.
just be on its right...avoid abusing it and just controlling is good...whethere it is bad or good,,,it should be sure so that no one can get confused..
This is readable to be a crumpled slider, but is picked by AImod to be "abnormal"
Would this be acceptable?
Would this be acceptable?
Topic Starter
it's definitely ugly.