Display the resultant difficulty settings after speed/rate changing

[vernonlim]

Currently, only the star rating display is changed with DT/speed changes, with no indication that other settings like AR or OD are affected. In stable, a small arrow is put next to the difficulty setting to indicate that it is raised (or lowered with HT), and the millisecond values displayed when hovered over are changed.

However, this isn't the terminology players use. In scoreposts and conversation, players use the AR/OD values calculated with formulas when discussing rate changed maps. An example is referring to AR9 + DT as AR10.3/AR10.33 and OD10 + DT as OD11/OD11.11 (decimals are usually omitted for convenience). It would be much less confusing for players if these values were displayed directly in the menu.

Instead of just SR, the other difficulty settings could be made red and increased to their values with the speed change (EDIT: in this case DT).

An example of this already implemented in the third party client McOsu, though without SR calculation due to it not being implemented. This implementation actually displays values rounded to 1 decimal place in the menu, and values rounded to 2 in the mod menu (in lazer, this should probably be all made 2 to be consistent with SR)

For ease of gameplay customization, this should somehow be applied to the 'Difficulty Adjust' mod as well (like it is in McOsu).

First, the values could be displayed permanently somewhere. Having to hover over a slider in order to see what value it is at is very inconvenient. (Could be another issue, but is required for this)

Then values after speed changing could be displayed next to the original values when DT/HT is selected. This way, players can see what the original value they are setting is, and what value they are going to get when playing with the selected speed.

The display of both original and after-speed-changing values is important since otherwise it would get confusing when working with complicated combinations of difficulty settings and speed changes (this is a flaw with McOsu's implementation from my own experience).

[ericshu6]

First, the values could be displayed permanently somewhere. Having to hover over a slider in order to see what value it is at is very inconvenient. (Could be another issue, but is required for this)

This is especially true for mobile.

[bdach]

@GameBoyYeet we know already

[vernonlim]

I forgot one of the most important things in the original post — BPM.
Currently, resultant BPM with DT/speed increase isn't displayed anywhere in the UI (unlike stable where it actually is in song select), so without a calculator/good mental math, players have no idea what speed the map is going to be.
It should be displayed clearly in both the song select menu and the mod customization menu.
Resultant length is also not displayed currently. In my opinion this should just be shown in the song select menu since it feels unnecessary to have it in mod customization.

[smoogipoo]

I’m gonna milestone this since I agree it’s important. At the very least BPM has to happen, the rest are QOL improvements that stable doesn’t have.

[Game4all]

Is there any particular design for the bpm and length indicators on the wedge when the bpm / length is affected by mods changing the time rate or maybe should it behave for now like on stable?

[bdach]

@Game4all I don't know anything about a design, but if you're planning to give this a shot, make sure you're handling ModTimeRamp correctly in the adjusted BPM calculations.

[Game4all]

Yeah, so far what I got locally seems to work fine but doesn't handle yet the non trivial case of wind up / down mods.

[bdach]

I believe accurately computing BPM bounds, given a linearly-changing BPM like in the case of ModTimeRamp, requires enumerating over all timing control points, and calculating minimum/maximum BPM within each section delineated by them.

[mk56-spn]

going to give fixing the length not adjusting with DT / HT a shot, unless someone is already on that

[bdach]

AR/OD now updates after #24642, but beatmap length is still not correct.

[Joehuu]

Beatmap length has since been updated in #26060. Closing as completed.