Doing this alleviates https://github.com/ppy/osu/issues/29982, as the
currently online display utilises the user lookup cache, and currently
is hitting rate limits due to the amount of data retrieved from the `GET
/users` endpoint. Switching to `GET /users/lookup` reduces the chance of
this happening.
People keep asking why https://github.com/ppy/osu/pull/29553 didn't fix
their databases (as stated in the PR, it didn't intend to), so this
should do it for them.
This is going to be used by server-side flows. Note that the server-side
overload of `UpdateFromLegacy()` was not calling
`LegacyScoreDecoder.PopulateTotalScoreWithoutMods()`.
Computing the score without mods inline reduces reflection overheads
from constructing mod instances, which feels pretty important for
server-side flows.
There is one weird kink in the treatment of stable scores with score V2
active - they get the *legacy* multipliers unapplied for them because
that made the most sense. For all intents and purposes this matters
mostly for client-side replays with score V2. I'm not sure whether
scores with SV2 ever make it to submission in stable.
There may be minute differences in converted score due to rounding
shenanigans but I don't think it's worth doing a reverify for this.
Closes https://github.com/ppy/osu/issues/28209.
Yes this means that such scores will have a zero total score without
mods in DB and thus might up getting their total recalculated to zero
when we try a mod multiplier rebalance (unless we skip scores with zero
completely I suppose). I also don't really care about that right now.
After way too much time investigating this, the encoding situation is
not great right now.
- Stable sets the "default code page" to be used for encoding filenames
to Shift-JIS (932):
c29ebd7fc5/osu!/GameBase.cs#L3099
- Lazer does nothing (therefore using UTF-8).
When importing to lazer, stable files are assumed to be UTF-8. This
means that the linked beatmaps don't work correctly. Forcing lazer to
decompress *and* compress using Shift-JIS will fix this.
Here's a rough idea of how things look for japanese character filenames
in current `master`:
| | stable | lazer |
|--------|--------|--------|
| export encoding | shift-jis | utf8 |
| utf8 [bit flag](https://superuser.com/a/1507988) set | ❌ | ❌ |
| import stable export osz | ✅ | ❌ |
| import lazer export osz | ❌ | ✅ |
| windows unzip | ❌ | ❌ |
| macos unzip | ✅ | ✅ |
and after this change
| | stable | lazer |
|--------|--------|--------|
| export encoding | shift-jis | shift-jis |
| utf8 [bit flag](https://superuser.com/a/1507988) set | ❌ | ❌ |
| import stable export osz | ✅ | ✅ |
| import lazer export osz | ✅ | ✅ |
| windows unzip | ❌ | ❌ |
| macos unzip | ✅ | ✅ |
A future endeavour to improve compatibility would be to look at setting
the utf8 flag in lazer, switching the default to utf8, and ensuring the
stable supports this flag (I don't believe it does right now).
Rather than creating a "corrupt" realm file in such cases, the game will
now refuse to start. This behaviour is usually what we want. In most
cases a second click on the game will start it successfully (the
previous instance's file handles are still doing stuff, or windows
defender is being silly).
Closes https://github.com/ppy/osu/issues/28018.
