I made these changes while working on
https://github.com/ppy/osu/pull/30579. Basically, it's hard to fix the
ranks not loading while underneath the footer, and the transparency both
looks bad, and is going away in the redesign.
I've chosen values here that are moving *in the direction* of the new
design without overhauling everything.
- I know that there's still some transparency. I did this because it
helps keep all current elements / colours contrasting without too much
effort.
- I completely removed the transparency adjustments on the beatmap
panels. This always looked bad due to being applied per-layer, and I
don't think it added much.
Related: https://github.com/ppy/osu/issues/30539
When starting up the game with a data location that points to an
unavailable external device, a new realm file is created in the default
location. Eventually a popup is shown that informs the user that the
external storage is unavailable, and the user has an option to try the
storage again. The button that invokes said option would check said
storage correctly, but would not do anything about realm, which means
the previously opened empty realm that is placed in the default location
would remain open, which means the retry essentially doesn't work
because the user's stuff isn't there after the retry.
To fix this, take out a `BlockAllOperations()`, which will flush all
open realms, and re-open the realm on the external location if the
custom storage restore succeeds.
This was another IRL request from a mapper / team member. The rationale
here is that it can be very annoying to map with break time enabled if
you have a large gap in the beatmap you are trying to fill with
hitobjects, as you are placing objects on top of a very gray area.
Fixes the root client-side failure causing
https://github.com/ppy/osu/issues/30415.
Thread of breakage is as follows:
1. `SongSelect` loads the carousel.
At this point, the ruleset is what the ambient ruleset would have
been at the time of pushing song select, so most likely it will
match the current ruleset.
Notably, the carousel is loaded with `AllowSelection == false`.
2. `OnlinePlaySongSelect` sets the ruleset to the one taken from
the relevant playlist item in `LoadComplete()`.
3. At any point between the previous and the next step, the user
changes the ruleset manually.
4. `SongSelect.carouselBeatmapsLoaded()` is ran, which calls
`transferRulesetValue()`, which calls `FilterControl.FilterChanged`.
But at this stage `Carousel.AllowSelection` is still false, so
the filter is not executed, but `pendingFilterApplication` is set
instead.
Unfortunately, the pending filter never gets applied after that.
The only place that checks that flag is `OnEntering()`, which at
this point has already ran.
To fix, move the `pendingFilterApplication` check to `Update()`, which
seems like the most obvious and safe solution.
I don't know why this was ever a good idea, and would say that we want
this to fail *hard* not soft. If things ever get in this state, things
have gone *seriously* wrong elsewhere, and need to be fixed there.
More specifically, this fixes placement blueprints not beginning placement when using touch input while the cursor was previously outside compose area, due to the placement blueprint not existing (removed from the scene by `ComposeBlueprintContainer`).
They will not only contract if the user chooses to have them contract
(new setting in the `View` menu) or if the game isn't wide enough to
allow full interaction with the playfield while they are expanded.
Addressess https://github.com/ppy/osu/discussions/28970.
Broke due to something changing in the way we handle realm things in the
carousel. The deselection happens in `updateBeatmapSet` so we need to
store / check the original selection before this occurs.
Doesn't seem this had test coverage? Probably implies that the overhead
of adding a test was very large, so maybe best to leave it that way.
Closes https://github.com/ppy/osu/issues/30163.
If I'm to be blunt, the decoupled stuff in song select makes my head
spin. I spent a solid 20 minutes thinking how I was going to fix this
one but then finally realised that generally most of the cause there
was the fact that `AdvancedStats` was seeing the new rulesets *before*
the "ensure global selected mods are valid for current ruleset" logic,
and so decided to just _delay_ that until the decoupled transfer
thingamajig happens.
I was honestly considering combining `BeatmapInfo`, `Ruleset`, and
`Mods` into one property on `AdvancedStats`. I figured I'd rather not
push my luck and try the baseline version first, but I honestly think
that direction is going to be required at some point to properly corral
all of the decoupled madness taking place in song select.
Fixes https://osu.ppy.sh/community/forums/topics/1983327.
The cause of the bug is a bit convoluted, and stems from the fact that
the mod select overlay controls all of the game-global mod instances if
present. `ModSpeedHotkeyHandler` would store the last spotted instance
of a rate adjust mod - which in this case is a problem, because on
deselection of a mod, the mod select overlay resets its settings to
defaults:
a258059d43/osu.Game/Overlays/Mods/ModSelectOverlay.cs (L424-L425)
A way to defend against this is a clone, but this reveals another issue,
in that the existing code was *relying* on the reference to the mod
remaining the same in any other case, to read the latest valid settings
of the mod. This basically only mattered in the edge case wherein Double
Time would swap places with Half Time and vice versa (think [0.95,1.05]
range). Therefore, track mod settings too explicitly to ensure that the
stored clone is as up-to-date as possible.
@peppy noticed recently that attempting to spectate just a few users was
very likely to end up in requests very quickly being rejected with code
429 ("Too Many Requests").
I'm somewhat certain that the reason for that is that a significant
number of players is wont to retry a lot in quick succession. That means
that spectator server is going to note a lot of gameplay start and end
messages in quick succession, too. And as it turns out, every gameplay
start would end up triggering a new beatmap set fetch request:
ccf1acce56/osu.Game/Screens/Spectate/SpectatorScreen.cs (L131-L134)ccf1acce56/osu.Game/Screens/Play/SoloSpectatorScreen.cs (L168-L172)ccf1acce56/osu.Game/Screens/Play/SoloSpectatorScreen.cs (L243-L256)
To attempt to curtail that, use the beatmap cache instead, which should
prevent these unnecessary requests from firing in the first place,
therefore reducing the chance of the client getting throttled.
This technically means that a different endpoint is used to fetch the
data (`GET /beatmaps/?ids[]=` rather than `GET
/beatmapsets/lookup?beatmap_id={id}`), but docs claim that both should
return the same data, and it looks to work fine in practice.
Compare: https://github.com/ppy/osu/pull/24548.
I don't have a reproduction scenario (judging from the stack trace
of the crash it's likely to be nigh-impossible to concoct a reliable
one), but there is some circumstantial evidence that this might help,
namely that that previous fix above worked, and the pathway that's
failing here is similarly async to the one that pull fixed. So I'm just
gonna start with that and hope that it does the job.
Closes https://github.com/ppy/osu/issues/29738.
This "regressed" in https://github.com/ppy/osu/pull/29639, but if I
didn't know better, I'd go as far as saying that this looks like a .NET
bug, because the fact that PR broke it looks not sane.
The TL;DR on this is that before the pull in question, the offending
`.Contains()` check that this commit modifies was called on a
`List<BeatmapSetInfo>`. The pull changed the collection type to
`BeatmapSetInfo[]`. That said, the call is a LINQ call, so all good,
right?
Not really. First off, the default overload resolution order means that
the previous code would call `List<T>.Contains()`, and not
`Enumerable.Contains<T>()`. Then again, why would that matter? In both
cases `T` is still `BeatmapSetInfo`, right? Well... about that...
It is difficult to tell for sure what precisely is happening here,
because of what looks like runtime magic. The end *symptom* is that the
old code ended up calling `Array<BeatmapSetInfo>.IndexOf()`, and the new
code ends up calling... `Array<object>.IndexOf()`.
So while yes, `BeatmapSetInfo` implements `IEquatable` and
the expectation would be that `Equals<BeatmapSetInfo>()` should be
getting called, the type elision to `object` means that we're back to
reference equality semantics, because that's what
`EqualityComparer.Default<object>` is.
A five-minute github search across dotnet/runtime yields this:
c4792a228e/src/coreclr/vm/array.cpp (L984-L990)
Now again, if I didn't know better, I'd see that "OPTIMIZATION:"
comment, see what transpired in this scenario, and call that
optimisation invalid, because it changes semantics. But I *probably*
know that the dotnet team knows better and am probably just going to
take it for what it is, because blame on that code looks to be years
old and it's probably not a new behaviour. (I haven't tested empirically
if it is.)
Instead the fix is just to tell the `.Contains()` method to use the
correct comparer.
