This design is about to get replaced, so I'm just making some minor
adjustments since a lot of people complained about the font size in the
last update.
Of note, I'm only changing the font size which is one pt size lower than
we'd usually use. Also overlapping the mod icons to create a bit more
space (since there's already cases where they don't fit).
Closes https://github.com/ppy/osu/issues/32055 as far as I'm concerned.
I can read everything fine at 0.8x UI scale.
The lack of this bricks chat completely due to newtonsoft
deserialisation errors:
2025-02-24 08:32:58 [verbose]: Processing response from https://dev.ppy.sh/api/v2/chat/updates failed with Newtonsoft.Json.JsonSerializationException: Error converting value "TEAM" to type 'osu.Game.Online.Chat.ChannelType'. Path 'presence[39].type', line 1, position 13765.
2025-02-24 08:32:58 [verbose]: ---> System.ArgumentException: Requested value 'TEAM' was not found.
2025-02-24 08:32:58 [verbose]: at Newtonsoft.Json.Utilities.EnumUtils.ParseEnum(Type enumType, NamingStrategy namingStrategy, String value, Boolean disallowNumber)
2025-02-24 08:32:58 [verbose]: at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.EnsureType(JsonReader reader, Object value, CultureInfo culture, JsonContract contract, Type targetType)
Flushes are assumed to have already come from a definitive state change
(read: disconnection). Allowing the exceptions that come from failing
the flushed requests to trigger the `Failing` code paths makes
completely incorrect behaviour possible.
Because it'll fail anyway - there is either no username or no password.
The reason why this is important is that the block was also setting API
state to `Connecting`.
When API is in `RequiresSecondFactorAuth` state, `attemptConnect()` is
called over and over in a loop, with no sleeping, which means that the
scheduler accumulates hundreds of thousands of these delegates. Sure you
could add a sleep in there maybe, but it seems pretty wasteful to have
the `localUser.IsDefault` guard *inside* the schedule anyway, so this is
what I opted for.
It seems that right now these timeouts do not check for actual data
movement, which is to say if a user with a very slow connection is
uploading and it takes more than `Timeout`, their upload will fail.
For now let's set these values high enough that most users will not be
affected.
In particular, when the exception is:
`AggregateException { AggregateException { HubException } }`,
then the existing code will only unwrap the first aggregate exception.
The overlay's code was copied from the extension so both have been
adjusted here.
