Number inputs in settings reset to default rather than min/max values when exceeding the range.

[Alphalaneous]

Geode Issue

• I confirm that this bug is NOT related to a mod but directly to Geode Loader itself.

Platform

Windows

SDK commit

No response

Geode Version

v3.8.1

Mods Installed

None

Expected Behavior

Entering a number within a mod's settings that is greater than the max or less than the min should set it to their min/max respectively rather than resetting the number to the default (especially since the range is not specified until you exceed it).

Actual Behavior

Entering a number within a mod's settings that is outside of the required range resets the value to default.

This is excessively annoying when you have any slider bypass hacks on, as you are forced to type it in. Earlier versions of settings did not have this issue.

Steps to Reproduce

• Entering a number within a mod's settings that is outside of the required range specified in the mod.json.
• Applying will reset the number to default

Additional Information

This happens on all platforms, but I could only select one.

[HJfod]

This was a fully intentional change to simplify settings code, imo if you bypass slider limits you get the consequences for bypassing slider limits

[Alphalaneous]

Completely disagree with this change, as well, this is a mod loader for a game, you should expect this sort of thing in some capacity. It only worsens the end user experience.

[HJfod]

The problem was that this is not generalizable to anything else. With strings, paths, colors, etc. there's no reasonable way to figure out the closest default value, this only applies to numbers and the specific case of min/max. If numbers ever gain an attribute like one-of, should it snap to the closest legal value? Right now every setting works the same: if the value is invalid, reset it to default. This is architechturally very simple to deal with, and is the expected behaviour for everything except arguably numbers (where I'd say the current behaviour is still logical and expectable). Using a bypass to be able to enter invalid values will get you invalid values.

[Alphalaneous]

The thing is you don't even need to use a bypass to enter invalid values, you could just type something too high and apply and it'll reset to default. The end user won't even know the range until they type an invalid one anyways. If you want to keep it like that, it should at least always show the range in some way.

[Alphalaneous]

To add, this runs into an even more annoying bug that you can't even backspace a number input all the way to type a new number as it always resets to default

[HJfod]

The settings do give clear errors of what is wrong and tell you the full wrong value. There's not really a good place in the UI to put range information statically, and besides, I reckon in most cases users should have an idea on what the expected range of values are (like bit rate, fps, etc.) or can just throw in a large value and see what it says.

[HJfod]

The backspace thing is a bug, that shouldn't happen

[Alphalaneous]

The settings do give clear errors of what is wrong and tell you the full wrong value. There's not really a good place in the UI to put range information statically, and besides, I reckon in most cases users should have an idea on what the expected range of values are (like bit rate, fps, etc.) or can just throw in a large value and see what it says.

We really shouldn't be assuming the user knows stuff, have ya see the help channel on the discord haha. I do get your point, in my honest opinion I do feel simplification of code should not outweigh the user experience, but overall, you do you, I'll just make a mod to fix this annoyance for myself lol

[HJfod]

What setting did you run into this issue with? I find it hard to imagine a situation where the exact range is both relevant to the user and not easily guessable