'Ignore speed multiplier' toggle for the Difficulty Adjust mod

[Flamiii]

Describe the new feature:
This is a simple toggleable option under the Difficulty Adjust mod that causes the AR and OD set in the mod to be unaffected by DT and HT speed multipliers and treated as if it was 1.0x.

How it currently works:
If you have DT (1.5x) enabled along with Difficulty Adjust set to AR 9, the resulting AR will be 10.33.

If you have DT (2.0x) enabled along with Difficulty Adjust set to OD 10, the resulting OD will be above 11.

How it would work with the 'Ignore speed multiplier' option enabled:
If you have DT (1.5x) enabled along with Difficulty Adjust set to AR 9 and with the 'Ignore speed multiplier' option enabled, the resulting AR will be 9, because the DT speed multiplier (1.5x) will be ignored and treated as if it was 1.0x.

If you have DT (2.0x) enabled along with Difficulty Adjust set to OD 10 and with the 'Ignore speed multiplier' option enabled, the resulting OD will be 10, because the DT speed multiplier (2.0x) will be ignored and treated as if it was 1.0x.

Why I believe it should be added:
Currently, I think Difficulty Adjust works great for changing values when DT and HT aren't enabled, but when they are, the AR and OD values can often become extremely high and while I know that they're able to be calculated, I think it can end up being pretty unintuitive for the player. In my case, I want this feature in the game so that I can be able to freely change the speed multipliers of maps ranging anywhere from 1.1x - 1.4x based on their difficulty without having to worry about the AR and OD values drastically changing as I adjust the speed multiplier. With this option enabled, I would be able to keep the AR and OD at 10 or 10.3 and not have to adjust it, even if I change the speed multiplier with DT or HT.

[respektive]

I agree with this, when playing with DT enabled and setting the AR to 9 I expect it to actually be 9 and not increased to ~10.33.

I think a better solution for this would probably be for DA to change the values after "rate changing" mods are applied instead of changing the base values.

[apollo-dw]

A potential solution would be changing difficulty settings displays with respect to rates across all the overlays, but I'm not sure whether that's the intended direction. This would remove the need for a toggle or any extra settings.

[respektive]

A potential solution would be changing difficulty settings displays with respect to rates across all the overlays, but I'm not sure whether that's the intended direction. This would remove the need for a toggle or any extra settings.

I think that's how it should display. HR is already changing the values on the Beatmap Details panel, I don't see a reason why rate changing mods like DT shouldn't.

[frenzibyte]

Because it's not that simple, DT/HT/NC/DC affect the speed of the gameplay clock itself, the beatmap difficulty values will have to be compensated in some way to achieve what the discusison thread is suggesting I believe (and that compensation needs to be done in a way that doesn't require intertwining logic between rate adjust mods and difficulty adjust mod).

Displaying the resultant difficulty values after toggling rate adjust mods is tracked in #10580.

[peppy]

From a developer perspective having the AR setting change post-clock applications breaks my head, because that's now how I've thought about the game working until now. It goes against other similar expectations like the animation speed of drawables tied to the gameplay clock, and if we want to go down this path maybe the whole rate application concept needs to be completely changed (hitobjects are moved, rather than time being sped up).

I'm not proposing this happens, because it would take months to make happen, but that's my perspective.

[tovc]

Bumping this thread because I think some sort of solution to this would be good. My current workaround is creating a mod combo for every rate adjust+AR I want to play. You can probably understand how that's not a great solution

I understand that there's probably some implementation issues on the back end, but as it stands, there's some serious usability issues on the front end. This is treading close to a question about design philosophy, but I don't believe that lazer's focus on clean code should get in the way of improving user experience. Then again, I certainly understand the issues associated with rewriting large parts of the engine, or introducing 'hacky' solutions to problems like these. Ultimately, I think it's enough to just say 'I want this feature' and leave it at that