Add ability to view other beatmaps in set when difficulties are grouped by set

[bdach]

Additionally pills corresponding to difficulties that are currently filtered out are now less prominent.

Screen.Recording.2025-12-30.at.12.53.12.mov

---

Closes #36039.

The part that makes this show the filtered out difficulties required some new crimes; see e07b828.

I have not done any benchmarking of this, want to see if this survives the initial review barrage.

[monochrome22]

Is it not possible to just display all the difficulties without going to that "temporarily showing all beatmaps" thing? The way it works now looks pretty frustrating to use, I think just expanding all the difficulties would be a noticeable UX improvement.

[bdach]

The way it works now looks pretty frustrating to use

why? have you even tried it? you don't even need to compile anything, this already went out in tachyon when difficulties are split (#36047) and you are the first person to complain

[monochrome22]

I tried it now and it's what I expected.

One way I use the show all difficulties feature is when I'm searching for a specific difficulty and I'm not sure which mapset it's in. Here's an example:

2025-12-30.18-07-41.mp4

I hope you can see how this process would be easier if I didn't have to jump back and forth between scopes. The same frustrations exist in other uses, though to a lesser degree.
I didn't say anything about the scoped mode in the other PR because I don't use split-apart mode and I thought you added it like that due to technical limitations, I didn't expect this convoluted UX to be added to normal mode by choice.

And while I'm giving my opinion: I think the dim on non-selected beatmapsets should be removed, it feels unnecessary, looks worse and sometimes can't see at all:

[bdach]

• you can press escape to back out of the scope, may make it less tedious than pressing the button every time
• this UX is designed to be a legible middle ground so we don't get reports of "help i accidentally clicked this 16px icon that didn't even attempt to indicate that it was clickable and something weird happened" that we regularly got with the previous behaviour
• am undecided on the dim, left it be because it's a visible indicator that only the selected set's toggle is interactable (that particular behaviour was a @smoogipoo request because he was pretty doubtful about bringing this feature back at all). could get rid of the dim if @peppy says so

at the end of the day the only person whose opinion i find relevant before this gets pushed to a mass release is @peppy's

[monochrome22]

this UX is designed to be a legible middle ground so we don't get reports

The discoverability is better this time (nice idea with the highlight bar and eye), so I would expect there to be fewer such reports.

it's a visible indicator that only the selected set's toggle is interactable

I personally don't feel it helps with understanding that the difficulty icons are clickable, I thought it was like that just because it's the selected set, I think most players would think the same.
For understanding it's clickable, one option is to display a dimmed eye.

It would only display on the selected beatmap set, and only if there are undisplayed difficulties. Players would be naturally curious what this eye icon means, and their first thought would be to hover it, which would show the highlight bar and light up the eye, making it obvious it's clickable. Could also add a tooltip to fully explain the function.

(appears after a short delay, same as other tooltips)

If that's still not enough, then could show the blue bar as a quick popup when revealing difficulties to explain what just happened.

I suggest improving discoverability and making the show all difficulties function work by just expanding the difficulties instead of resorting to the more convoluted UX of changing scope.

[bdach]

dim has been removed as @peppy agrees with removing it. i'm not going to do anything else with the above feedback until this sees a larger release. acquiescing to every possible github passerby is neither sane or feasible.

[monochrome22]

It's not about "acquiescing", it's about improving the feature (and by extension, the game). It feels that you're thinking that if you do it my way, then you'll be "giving in to demands" or something, when you should really be looking at it as a suggestion, as in, if you look at my posts and think "yeah, that UX would be better", then you could add it like that.
I do think my way is noticeably better and I hope it ends up being that way, but I'll be glad if this feature gets added in any form. That's all I wanted to say, sorry if this post is inappropriate for a PR thread.

[peppy]

I'm fine with this being implemented how it is as a first pass. I can understand @monochrome22's concern for their specific use case, but I'd want to hear more user feedback before considering a different approach. What we have here is well defined and matches the non-grouped display flow too.

[cloudrac3r]

Thank you so so so so so much for bringing this back.