This used to already be the case prior to b419ea7, but in a very
roundabout way. Changes to the value of the star difficulty bindable -
including indirect changes via the set of active mods changing - would
trigger the wedge display to regenerate and load asynchronously.
b419ea7 accidentally broke this by moving down the bindable retrieval to
a lower level, at which point `WedgeInfoText` would only receive the set
of mods selected at the time at which a given beatmap was selected, and
not receive any further updates, breaking the BPM display updating in
real time (as `WedgeInfoText` could not be aware that rate-changing mods
were even in effect).
To resolve, explicitly reload the wedge's contents on mod changes.
This fixes the whole issue behind `Ruleset.Value` being null, by
updating `Current` on BDL rather than waiting for the base logic which
executes at `LoadComplete`.
This seems like something that should happen at the base `TabControl` class itself, by switching `Current` right after the first added tab item, rather than doing it on `LoadComplete`, but I'm not sure about changing framework logic outright, so fixing this locally until it occurs on other places.
`DifficultyCacheLookup`s were storing raw `Mod` instances into their
`OrderedMods` field. This could cause the cache lookups to wrongly
succeed in cases of mods with settings. The particular case that
triggered this fix was Difficulty Adjust.
Because the difficulty cache is backed by a dictionary, there are two
stages to the lookup; first `GetHashCode()` is used to find the
appropriate hash bucket to look in, and then items from that hash bucket
are compared against the key being searched for via the implementation
of `Equals()`.
As it turns out, the first hashing step ended up being the saving grace
in most cases, as the hash computation included the values of the mod
settings. But the Difficulty Adjust failure case was triggered by the
quirk that `GetHashCode(0) == GetHashCode(null) == 0`.
In such a case, the `Equals()` fallback was used. But as it turns out,
because the `Mod` instance stored to lookups was not cloned and
therefore potentially externally mutable, it could be polluted after
being stored to the dictionary, and therefore breaking the equality
check. Even though all of the setting values were compared, the hash
bucket didn't match the actual contents of the lookup anymore (because
they were mutated externally, e.g. by the user changing the mod setting
values in the mod settings overlay).
To resolve, clone out the mod structure before creating all difficulty
lookups.
Intentionally not using `[Values]` as the scale modes can be applied to
the running game instance directly, rather than recreating it all over
again.
The same could be said for the notification overlay but not sure, seems
like something that should be considered at an `OsuGameTestScene` level
instead (whether the same game instance can be reused for further
testing).
By using `Content` instead, now the logic will get the X of the settings
overlay at the `Content` space, which can be scaled in the
`ScalingMode.Everything` mode.
And in the case of `ScalingMode.ExcludeOverlays`, a subcontainer
somewhere inside `Content` that's holding the screen stack would be scaled,
but `Content` won't be affected which is what we want in that case.
