Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. Beatmaps
  3. Mapping Discussion
  4. Ranking Criteria
  5. Finalized/Denied Amendments

[proposal - std] let spinners start/end less than 1/16 from the prior/following object

posted
Total Posts
26
quila
358 posts
Joined February 2016
Topic Starter
quila
title. mapper discretion would still exist, so people would still be able to choose to have a spinner start on 1/16, 1/8, 1/4, 1/2, etc snap, as they do now.

i think this would be a positive change because it can be preferred in some cases, like when one wants players motions to count towards the spinner from the moment they click the prior object, or when they want to make a spinner just a little easier by extending it a bit. (or if you think this would actually make a spinner harder, then it could be used when someone wants to make a spinner just a little harder)

one possible way to word this would be to change this:
Objects must be snapped to timeline ticks [...]
to this:
Circles and sliders must be snapped to timeline ticks [...]
(but this would be changing the global rc, not just STD's, and would allow unsnapped spinners that don't do this, which people might not want)

another possible way would be to keep it as "Objects must be snapped to timeline ticks [...]", but add an exception saying something like "in standard, spinner starts and ends can be unsnapped according to AImod if they're less than 1/16 away from the prior/following object"
Last edited by quila , edited 7 times in total.
1103
276 posts
Joined October 2015
1103
1ms difference between circle and spinner, i like it
quila
358 posts
Joined February 2016
Topic Starter
quila
an update: in taiko converts, if a big taiko circle comes 1ms before a spinner, it will fully cover the spinner. this is not true for the small circles in taiko.

may want to have a clause preventing this from happening, since it can be avoided by using different files for the same hitsounds im pretty sure

in standard, spinner starts and ends can be unsnapped according to AImod if they're less than 1/16 away from the prior/following object. if this is done, the spinner must not be fully obscured by a large circle in taiko converts.
examples with screenshots
a small taiko circle 1ms before a spinner


a small taiko circle 1/16 before a spinner at 163 bpm (22ms)


a large taiko circle 1ms before a spinner


a large taiko circle 1/16 before a spinner at 163 bpm (22ms)
Last edited by quila , edited 1 time in total.
Mizunashi Akari
181 posts
Joined August 2018
Mizunashi Akari
if we aren't talking converts i don't see why this isn't a bad change. I dont feel unsnapped spinners do anything bad to std as long as we're still following basic spinner length guidelines and rules, since they're basically nonactive and all they require is a visual cue to start spinning, without any sense of rhythm

edit: apparently in mania 1k converts its possible for it to become almost impossible to hit, since spinners become a held note, so can we just delete converts alltogether :^)
Last edited by Mizunashi Akari , edited 5 times in total.
Goatlov3r
8 posts
Joined May 2016
Goatlov3r
Seems like a good idea o:
Last edited by Goatlov3r , edited 1 time in total.
quila
358 posts
Joined February 2016
Topic Starter
quila
someone mentioned that objects less than 5ms apart might cause bugs, but didn't specify any bugs. this should probably be considered. does anyone have info on what bugs these are, if any?

edit: if we don't get more info on this, we could simply allow this for the time being provided objects are not within 5ms of each other, like this:

in standard, spinner starts and ends can be unsnapped according to AImod if they're less than 1/16 but more than 5ms away from the prior/following object. if this is done, the spinner must not be fully obscured by a large circle in taiko converts.
Last edited by quila , edited 4 times in total.
clayton
1,928 posts
Joined November 2013
clayton
"5ms" seems pulled from nowhere, I'd just ignore that comment, there are lots of unranked maps with spinners on top of or right after other objects and they work fine. also I don't think converts should be a topic for this since the logic for conversion isn't changed in any way and it's just a looser timing restriction than 1/16 already is (already very small... 15.6ms at 240BPM for example)

I can't come up with an example where this would be a harmful addition but it also just feels like a hack to have things not snapped to rhythm at all in a ranked map... I'll just wait for more comments /shrug
quila
358 posts
Joined February 2016
Topic Starter
quila
but it also just feels like a hack to have things [spinners] not snapped to rhythm at all in a ranked map
in most cases, spinners that are snapped 1/16 away from another object are not snapped to rhythm either. i think it's been demonstrated through all the ranked maps where spinners don't start on a distinct sound that this isn't detrimental to player experience
Last edited by quila , edited 1 time in total.
quila
358 posts
Joined February 2016
Topic Starter
quila
also, i agree we can probably ignore the comment about objects less than 5ms apart causing bugs. the person who made that comment hasn't gotten back to me in around 10 days, anyways

on another note, could this get some more discussion? it's definitely not urgent, but i don't want to see this thread become inactive either
Naxess
Nomination Assessment Team
390 posts
Joined March 2016
Naxess
If we're going to allow spinners to appear less than 1/16 away from the previous object, we might as well instead allow them to be concurrent with that object (for circles / slider ends / spinner ends). This way it's both easier to apply in maps without .osu editing, and easier to implement into the RC; simply make an exclusion in the concurrent rule:

No two hit objects can be placed on the same tick. This includes hit circles and the durations of sliders and spinners. osu!mania beatmaps are exempt from this. The beginning of spinners in osu!standard may be placed on the same tick as a hit circle, slider end, or spinner end.
As far as I've found:
- For taiko converts, this results in auto missing the object before the spinner, but a player can still FC 100%.
- For mania converts, this places the object and the spinner on different columns.
quila
358 posts
Joined February 2016
Topic Starter
quila
seems good, but what about spinner ends - can they be on the same tick as a circle/sliderhead, or right before it? your quote only mentions spinner starts in this sense

This way it's both easier to apply in maps without .osu editing
by the way, it's possible to unsnap objects without .osu editing by holding shift and dragging an object on the timeline

important edit: it looks like having spinners start on the same tick as a circle sometimes but not always causes bugs in osu!standard. i can't make a recording since my pc is slow, so try playing auto on this test diff (goes with this set). the 4th spinner should break

some potential options:
- use my first proposed implementation instead (i.e add an exclusion to the rule about unsnapped objects)
- determine what causes this and include a clause saying it has to be avoided
Last edited by quila , edited 8 times in total.
lewski
1,346 posts
Joined September 2014
lewski
The fourth spinner does break, it doesn't count for combo at all. It was really easy to fix, though, I just dragged it to another tick and back and saved. The problem seems to come from the spinner being before the circle in the .osu, since my fix reversed the lines. Spinner before circle seems to destroy star rating as well:

However, the second spinner is also before its corresponding circle and it works perfectly well. I was also unable to reproduce the issue; adding more stuff like this to the diff even fixed the fourth spinner.

I also couldn't find any issues with spinner ends being on the same tick as another object (or even with having the end of one spinner, a circle, and the start of another spinner all on the same tick). Fwiw my testing wasn't super thorough, but I do think we could implement Naxess' proposal on the condition that the objects are ordered properly in the .osu.

It's actually pretty easy for modders to tell when there's a problem if they know what they're looking for, since improperly ordered circles and spinners are pretty clearly visible on the timeline in the editor with most combo colours:
bad
good
Last edited by lewski , edited 1 time in total.
quila
358 posts
Joined February 2016
Topic Starter
quila
thanks lewski!

i modified naxess' implementation to allow spinner-ends and added a new clause linking back to your post:
No two hit objects can be placed on the same tick. This includes hit circles and the durations of sliders and spinners. osu!mania beatmaps are exempt from this. Spinner starts and ends in osu!standard may be placed on the same tick as as the closest object, so long as the two are ordered correctly in the .osu file
Last edited by quila , edited 2 times in total.
Naxess
Nomination Assessment Team
390 posts
Joined March 2016
Naxess

quila wrote:

seems good, but what about spinner ends - can they be on the same tick as a circle/sliderhead, or right before it? your quote only mentions spinner starts in this sense
That's intentional - ending a spinner on the same tick as an aimed object just results in the player ignoring the spinner and aiming at the next object instead, same as being 1/16 apart, so that adds nothing to the gameplay experience, rather takes away from it unfairly.

Starting a spinner on the same tick, however, works as one fluid motion, similarly to sliders (click + hold + aim):
- circle -> spinner: click + hold + spin
- slider -> spinner: click + hold + aim + spin
- spinner -> spinner: click + hold + spin + spin

If that makes sense.
quila
358 posts
Joined February 2016
Topic Starter
quila
it makes sense in theory, but aiming and spinning don't have to be separate; the movement of a player's cursor while 'aiming' or moving towards the next clickable object counts towards the spinner, too.

if the player reaches the next object and hovers over it for a bit before clicking, what you say would be true. but players don't always do this, and i think it's likely they would intentionally not do it when a map requires they don't (otherwise they would i.e get a low score on a spinner. or in other cases where players don't have time to hover over an object before clicking, they might miss a slider-end on the previous object if they tried to do so via moving off of it too early)

here's an example. sorry for the low vid quality, my pc is weak as i mentioned before
here's the same play in a lower resolution, but less laggy
here's a play on a version with the circles further away and in random locations on the screen, to further demonstrate this
Last edited by quila , edited 7 times in total.
Naxess
Nomination Assessment Team
390 posts
Joined March 2016
Naxess
Spinning at expert difficulty level is generally pretty fast, and I don't think we should expect players to be able to aim consistently while going at 350+ RPM. The technique you're describing is basically just spinning until the very last moment, then slowing down to aim, optionally releasing the button held (if the player doesn't alternate), and finally pressing again.

The first step of this generally begins way before the 1/16th tick, as 16 ms (assuming 180 bpm) is already too small of a timeframe to transition from spinning at high speed to aiming accurately, especially if the next object is far from the center of the screen. Hence why I think adding additional spinner time after that would contribute nothing, and only be detrimental to the gameplay experience.
1103
276 posts
Joined October 2015
1103
i feel like as long as its possible for a player of a high calibre to get a 300, it is completely acceptable. all this is is a vehicle for expressing the music. i also do not think it is appropriate to generalize players slowing down to hit the next circle to a point where it would be unfair as that is not necessarily true of any given map
Last edited by 1103 , edited 5 times in total.
quila
358 posts
Joined February 2016
Topic Starter
quila

Naxess wrote:

I don't think we should expect players to be able to aim consistently while going at 350+ RPM.
i'll ask some better players to try doing this consistently and report back to this thread

The first step of this generally begins way before the 1/16th tick, as 16 ms (assuming 180 bpm) is already too small of a timeframe to transition from spinning at high speed to aiming accurately
'slowing down to aim' while the spinner is active would be a part of intended play i imagine - at least in the hard way i showed above. it couldn't be intended for players to transition from high-speed spinning to 'aiming' only after the spinner ends; that would actually be impossible if a spinner ends on the same tick as the next clickable object.

it's possible that a spinner that ends on the same tick as a clickable object would be played no differently than a spinner that ends 1/16 earlier. even then, i don't see how this would be detrimental to player experience (rather than neutral), and i think it can be positive to the degree that it influences game feel (even if it doesn't effect the required motions themselves)


i hope this makes sense, please let me know if anything doesn't :)
Last edited by quila , edited 1 time in total.
Naxess
Nomination Assessment Team
390 posts
Joined March 2016
Naxess
Well, I'll let you keep gathering thoughts here.

In summary:
- The "prior" portion seems good to me, and has perks such as instantly giving spinner feedback as the prior object is clicked (the 1/16 gap is visually noticeable here), and melds well into the way other gameplay aspects work, such as sliders.
- The "following" portion I'm unsure what the point of is, given that you can achieve the desired effect already (?). Adding the ~0.016th of a second gap before the next object as expected spinner time will probably neither be spent spinning properly nor even noticed, and so seems kinda pointless to make an exception for. Maybe testplays will prove that wrong, though.
quila
358 posts
Joined February 2016
Topic Starter
quila
one testplay so far by rlsc on a test diff i made. i think they played it right
another testplay by rho

here's the diff; goes with spro's graces of heaven set
Last edited by quila , edited 3 times in total.
quila
358 posts
Joined February 2016
Topic Starter
quila
i'd like to merge the partial version of this proposal that naxxess suggested. this thread can be left as unarchived for more discussion on the spinner-ends part of it

their suggested implementation with an added link back to lewski's post:
No two hit objects can be placed on the same tick. This includes hit circles and the durations of sliders and spinners. osu!mania beatmaps are exempt from this. The beginning of spinners in osu!standard may be placed on the same tick as a hit circle, slider end, or spinner end, as long as the two are ordered correctly in the .osu file

i made a pull request, hope i did it right. https://github.com/ppy/osu-wiki/pull/4820
Last edited by quila , edited 4 times in total.
quila
358 posts
Joined February 2016
Topic Starter
quila

peppy wrote:

Two hit circles should not exist at the same time value. The only exception for this is mania.

This may change in the future but is how it is for now. Please place the spinner closer but not at the same millisecond value as another hit object.
looks like we should change back to the original implementation. here it is, as simple as i can make it

Objects must be snapped to timeline ticks according to AiMod. In osu!standard, spinner starts that are within a 16th of a beat from the prior object are exempt from this. Objects in a musical section requiring unsupported beat snap divisors (e.g. 1/11) can either: [...]
Last edited by quila , edited 4 times in total.
peppy
19,318 posts
Here since the beginning
peppy
Just to confirm, would adding an exception in AiMod to ignore spinners which are close (in time value) to the previous hitobject? Something like <50ms? This is the simplest approach for me to implement, rather than limiting based on the "snap divisor", which seems quite arbitrary in this case.
quila
358 posts
Joined February 2016
Topic Starter
quila

peppy wrote:

Just to confirm, would adding an exception in AiMod to ignore spinners which are close (in time value) to the previous hitobject? Something like <50ms? This is the simplest approach for me to implement, rather than limiting based on the "snap divisor", which seems quite arbitrary in this case.
yes, that would work
SilentWuffer
289 posts
Joined December 2017
SilentWuffer
I feel like this isn't too bad of a change, but we would need to add more guidelines like the easy one for spinners ending a bit earlier so beginners have more time to read.

another thing, there's a hitsound at the end of a spinner so if it ends on an arbitrary ms it would sound off (you could just remove its hitsound though ig but that might go against rc)
Last edited by SilentWuffer , edited 1 time in total.
Noffy
Nomination Assessment Team
1,685 posts
Joined April 2012
Noffy
Actually, the change ppy suggested was implemented already. Spinners close to a previous object don't check for unsnaps in those cases. Going to archive.
Please sign in to reply.

New reply

0
1 / 26