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.
The previous logic was very wrong, as the check would only occur on each
beat. But that's not how kiai sections work – they can be placed at any
timestamp, even if that doesn't align with a beat.
In addition, the rate limiting has been removed because it didn't exist
on stable and causes some fountains to be missed. Overlap scenarios are
already handled internally by the `StarFountain` class.
Closes https://github.com/ppy/osu/issues/31855.
Closes https://github.com/ppy/osu/issues/31915.
Reproduction of aforementioned issue requires 1280x720 resolution, which
should also be a good way to confirm that this does anything.
To me this is also equal-parts-bugfix, equal-parts-code-quality PR,
because tell me: what on earth was this code ever doing at
`ComposeBlueprintContainer` level? Nudging by one playfield-space-unit
doesn't even *make sense* in something like taiko or mania.
Closes https://github.com/ppy/osu/issues/31909.
Previously: https://github.com/ppy/osu/pull/30062.
Happening because of rounding errors - in this case the beat index
pre-flooring was something like a 0.003 off of a full beat, which would
get floored down rather than rounded up which created the discrepancy.
But also we don't want to round *too* far, which is why this
frankenstein solution has to exist I think. This is probably all
exacerbated by stable not handling decimal control point start times.
Would add tests if not for the fact that this is like extremely annoying
to test.