Add property for "invisible" slider tick/end (account for 36ms offset in slider-end calc)

[MaxKruse]

As seen in https://twitter.com/ppy/status/1245162168951042048

the sliderend is calculated 36ms before the actual sliderbody ends. I was planning to use this lib for some pp calculators and want to get the best possible accuracy.

Would it be possible to have another property, similar to Slider.tick_points which would maybe be called Slider.true_tick_points ?

To further elaborate, only the last tick is offset by these 36ms, not any repeats.

[tybug]

yeah, we can definitely make this happen.

I’d like to look at lazer’s source code to try and understand what this invisible slidertick does first - does it count towards scoring / combo? If you miss it, do you sliderbreak? Is it present on sliders shorter than 36ms? does it matter for pp calculation? If it acts like a regular slidertick in every regard then I don’t see why we shouldn’t add this to the normal slidertick method and consider it a bugfix change, not a breaking change which requires a new method. (but of course if it is different then I agree a new method, or rather a new tick_points(include_invisible_tick=True) parameter is appropriate)

If you already understand how this slidertick acts in the above scenarios and are willing to make a PR I’d be much obliged. Otherwise I’m on vacation until the 30th, so won’t get to this for a bit.

[MaxKruse]

The invisible slidertick is used in judgement checks, e.g. you can aim onto the actual sliderend on a fast slider but still get a 100 because the game thinks you missed - when in fact one hit the sliderend, but not the invisible slidertick.

A video explaining this behaviour is here: https://www.youtube.com/watch?v=zYAujNMPVbY

To address your questions:

• It does not affect scoring or combo, it acts like the sliderend
• Missing on it will act as if you are missing the sliderend, giving you 0 to your combo and a 100 instead of a 300
• It is only present on sliders that are > 36ms. And dont have repeats. As those sliders will feasibly never be longer than their sliderball radius, for the purpose of calculation anything >= 37ms or longer in total will be affected

• For current pp calculation, this does not matter as sliderbodies are entirely ignored. However, me and somebody else i want to leave unnamed are working on new pp prototypes which will involve sliders, their shapes and where the actual judgement for the slidertail is

  My proposed implementation is to replace the last slidertick (which is as far as i understand the slidertail) with the -36ms offset, and not adding a new one.

  Im not as into python, so i think your proposed idea for the arg will work.

  I am not at all confident in making a working implementation for this as my brain is very small and i know how things work and how i'd expect them to work, but im too pepega to actually implement anything. Waiting is a valid solution for now, and i will develop further with the current slidertail in mind, making a drop-in replacement of the lib's version easy and viable.

  Thanks for your time :D

[tybug]

thanks for the link and explanations. I'll try to wrap my head around and implement it this/next week.

[kpei]

@MaxKruse if you are willing to port code, abstrakt's rewind in js has a very good working impl of beatmap and gameplay evaluation. Feel free to check it out.

[MaxKruse]

Small Bump if this is still something i should PR myself or @tybug is willing to port - both are fine to me

Edit: Code in question https://github.com/abstrakt8/rewind/blob/ed74dafa965b41185c4b0720344013449c1c6ace/libs/osu/core/src/hitobjects/slider/SliderCheckPointGenerator.ts#L29 and https://github.com/abstrakt8/rewind/blob/ed74dafa965b41185c4b0720344013449c1c6ace/libs/osu/core/src/blueprint/HitObjectSettings.ts#L34

[tybug]

@MaxKruse please do make a PR if you're willing - I did look into this but wasn't confident I could implement something which matched gameplay.