Settings/options menu does not load in rare cases

[spdragon0]

Type

Game behaviour

Bug description

Settings menu shows loading animation, but nothing happens. Runtime log shows a division by zero exception.
This occurred after trying to open the menu using Ctrl-O after about 1 hour of gameplay. Re-opening the menu doesn't work, but restarting the game seems to fix the issue.

Screenshots or videos

No response

Version

2024.1009.1

Logs

1731644629.auth.log
1731644629.database.log
1731644629.nauth.log
1731644629.network.log
1731644629.performance.log
1731644629.runtime.log

[smoogipoo]

2024-11-15 05:08:03 [error]: An unhandled error has occurred.
2024-11-15 05:08:03 [error]: System.DivideByZeroException: Attempted to divide by zero.
2024-11-15 05:08:03 [error]: at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
2024-11-15 05:08:03 [error]: at osu.Framework.Graphics.UserInterface.SliderBar`1.<.ctor>b__12_5(ValueChangedEvent`1 e)
2024-11-15 05:08:03 [error]: at osu.Framework.Bindables.Bindable`1.TriggerValueChange(T previousValue, Bindable`1 source, Boolean propagateToBindings, Boolean bypassChecks)
2024-11-15 05:08:03 [error]: at osu.Framework.Bindables.BindableNumber`1.setValue(T value)
2024-11-15 05:08:03 [error]: at osu.Framework.Bindables.Bindable`1.TriggerValueChange(T previousValue, Bindable`1 source, Boolean propagateToBindings, Boolean bypassChecks)
2024-11-15 05:08:03 [error]: at osu.Framework.Bindables.BindableNumber`1.setValue(T value)
2024-11-15 05:08:03 [error]: at osu.Framework.Bindables.BindableNumber`1.CopyTo(Bindable`1 them)
2024-11-15 05:08:03 [error]: at osu.Framework.Bindables.RangeConstrainedBindable`1.BindTo(Bindable`1 them)
2024-11-15 05:08:03 [error]: at osu.Framework.Graphics.UserInterface.SliderBar`1.set_Current(Bindable`1 value)
2024-11-15 05:08:03 [error]: at osu.Game.Overlays.Settings.SettingsItem`1.set_Current(Bindable`1 value)
2024-11-15 05:08:03 [error]: at osu.Game.Overlays.Settings.Sections.Gameplay.AudioSettings.load(OsuConfigManager config, OsuConfigManager osuConfig)
2024-11-15 05:08:03 [error]: at osu.Game.Overlays.Settings.Sections.Gameplay.AudioSettings.<>c.<RegisterForDependencyActivation>b__3_0(Object t, IReadOnlyDependencyContainer d)

Following the IL, it looks like it's happening here:

https://github.com/ppy/osu-framework/blob/20c0c2ccaae04e28a2648a803c917519b75d7777/osu.Framework/Graphics/UserInterface/SliderBar.cs#L77-L81

Which leads to perhaps this division?

https://github.com/ppy/osu-framework/blob/20c0c2ccaae04e28a2648a803c917519b75d7777/osu.Framework/Bindables/BindableNumber.cs#L82

But I'm not sure why, precision shouldn't be 0 there.

[peppy]

The only gameplay usage of this bindable is

osu/osu.Game/Rulesets/Objects/Drawables/DrawableHitObject.cs

Line 202 in ad2cd0b

positionalHitsoundsLevel.BindTo(gameplaySettings.PositionalHitsoundsLevel);

It's binding a Bindable to a BindableNumber which one might argue could break precision in some way? But I can't reproduce no matter what scenario I test with. Unless this happens to more users I feel like this might be a dead end cause to investigate further.

[frenzibyte]

PositionalHitsoundsLevel never had a sane precision set by default in the first place, probably safe to say it plays a very major role here.

[frenzibyte]

As per discussion on discord, the cause of this exception cannot be explained by any parts of our codebase. The only possible culprit here to trigger this exception is Precision being zero and this line dividing by Precision, but if you look at the if conditional surrounding that line, it should guarantee that Precision is greater than the data type's default precision, which immediately shows two crucial points:

• Precision must be greater than zero, since the default precision is epsilon and that is certainly greater than zero...but we got a division by zero??
• Precision must be greater than default precision, but the setting never had its precision touched, so it must be equal to default precision...hello?

This is beginning to resemble an issue we've seen a while ago where certain platform configurations behave weirdly around floating point comparisons.

I've just went the easy way and actually specified a precision for all config settings because I cannot imagine us exposing settings with epsilon-level precision anyway. However, if the above is true and some platform configurations are breaking apart on epsilon precision, then this implies that any BindableNumber<T> with epsilon precision will always cause the game to die on such platforms, so I guess we may want to rectify this at an o!f level still if someone can somehow reproduce this.

[bdach]

any BindableNumber<T> with epsilon precision will always cause the game to die on such platforms

That would be very bad news since we want epsilon precision on bindables sometimes, especially in stuff like control points on legacy maps, wherein you really don't want to be rounding any of the values. So hopefully it's not that.