Resolves one part of
https://github.com/ppy/osu/discussions/32568#discussioncomment-12612928
A few caveats:
- Layout is slightly different than web intentionally. Web does things
that I think will be difficult to reproduce or just plain look bad in
client, such as:
- On web, the metadata info box has 200px min height and 300px max
height. I just hardcoded 300 units.
- On web, user tags and mapper tags are individually scrollable, and
the amount of space taken up by each is calculated in a way that
is - as far as I can tell - indeterminate, and probably influenced
by some flexbox magic. I just made the entire thing scrollable
instead.
- Because song select shares controls with the beatmap set overlay, now
song select says "Mapper Tags" in the header instead of just "Tags"
too. I think this is fine, because people asked for user tags to be
shown in song select too.
- Search query syntax lifted from
https://github.com/ppy/osu-web/pull/12047.
- Using hardcoded English strings for now, will update to the
translations after the next osu-resources localisations update.
This is in response to
https://osu.ppy.sh/community/forums/topics/2058708?n=5, wherein the user
is having a problem with joining multiplayer, but I have basically no
diagnosing capabilities, because the logs are all
2025-03-26 18:57:57 [error]: Failed to join multiplayer room:
2025-03-26 18:58:40 [error]: Failed to join multiplayer room:
2025-03-26 18:58:41 [error]: Failed to join multiplayer room:
2025-03-26 18:58:41 [error]: Failed to join multiplayer room:
which appears to originate from
https://github.com/ppy/osu/blob/c82eaafe98d96b9f49a4a7f168ef5c484e67d76f/osu.Game/Screens/OnlinePlay/Multiplayer/MultiplayerLoungeSubScreen.cs#L91
Now, as far as I can tell, there are two possibilities here:
1. The exception's `Message` is null or empty. That's not exactly great
or typical, but sure, this could possibly happen - in which case the
error logging is silently eating whatever little relevant detail
there is left to use.
2. The exception is *actually* `null` itself, and we're in the X Files.
This PR is intending to defend against (1).
In examining the logging further, I also spotted the following issues:
- In the single path that specifies a custom failure handler (which is
`DrawableLoungeRoom` which handles joining a passworded room), the
custom failure handler being present means that the error would be
presented to the user, but it would not be logged. At all.
- In playlists, if the exception for whatever reason had an empty
message, an empty notification would get posted. And in general to me
it feels a bit dodgy to be directly presenting exception notifications
to users without any preamble, hence the added "Failed to open
playlist" prefix.
At the core of the problem is that the multiplayer server does not
serialise beatmap covers to clients -- only the beatmap ids. Because of
this, any components that need to display the background should query it
from an online source first (i.e. via `BeatmapLookupCache`).
There is a slightly tricky situation here formed of two parts, which
I'll try to explain below.
`Background.Sprite` is exposed publicly and some inheritors override the
sprite's texture in a similar fashion to the way this changeset does.
While I frankly believe this is unnaceptable from an encapsulation point
of view, I've gone for consistency in this regard.
The other fail case is `UpdateableBeatmapBackgroundSprite`. Contrary to
its name, that object is _not_ a `Sprite` - it is a
`ModelBackedDrawable` that _contains_ a `Sprite`. The logic in this PR
could be extracted into a separate object similar to
`OnlineBeatmapSetCover` (an actual `Sprite`), but even so it would
require `Background` to provide a path for overriding its contained
`Sprite`.
I went through the path above originally with the changes visible in
https://github.com/smoogipoo/osu/tree/fix-mp-backgrounds, but it looks
quite daunting and I feel like there would be a lot of emphasis on the
correct abstraction model for `Background`, of which I'm not entirely
sure of.
Instead of dealing with both of the above, this commit presents a
direct; local resolution to the problem.
Noticed during review of https://github.com/ppy/osu/pull/32571.
The reproduction scenario is as follows:
1. Download beatmap used in daily challenge
2. Go to editor and modify it
3. Go to daily challenge, wherein the availability tracker will notice
the MD5 mismatch, block the button, and require a redownload
4. Redownload the beatmap
5. Start gameplay
6. Gameplay start will fail due to web not issuing a submission token
because the attempt to start gameplay ended up using the modified
version of the map from step (2) rather than the redownloaded
original from step (4).
Thankfully, due to (6), this is not exploitable, but nevertheless pretty
bad.
Probably regressed somewhere around
https://github.com/ppy/osu/pull/31747 actually.