SettingNumberInput crashes in game

[underscoreevelyn]

My mods and Everest install are up to date

Yes

I have recreated the bug with only Everest OR a minimum number of mods enabled

Yes

Describe the bug

Trying to change a setting with SettingNumberInput while in game crashes.

Steps to reproduce

1. Create a mod with a SettingNumberInput setting. The arguments don't matter.
2. Enter a level. It doesn't crash in the overworld.
3. Select the setting.

Expected behavior

Given that the number input is an Oui element like the string input, I think the setting just shouldn't show up in game, like with strings. However, reworking the number and string inputs to work in game is the more correct fix, in my opinion.

Operating System

Linux

Everest Version

4896

Mods required to reproduce

Any mod that uses SettingNumberInput, which may be none of them? IDK how this hasn't been noticed before.
Here's a sample mod.

Additional context

log.txt

[WEGFan]

I modified string inputs into entity in my mod, and made them changable in level. Theoretically it could be used to replace the current implementation in Everest but it's a bit messy and I remember there are some small bugs in it.

https://github.com/WEGFan/Celeste-Trailine/blob/master/Code/UI/

[SnipUndercover]

I'm pretty sure input OUIs are unsupported outside of the overworld and require a [SettingInGame(false)] attribute to prevent them from appearing in-game.

This is what's done for string properties already, though this should probably be documented and/or handled to gray out [SettingNumberInput] properties if the player's in-game.

[RedFlames]

It's here

Everest/Celeste.Mod.mm/Mod/Module/EverestModule.cs

Line 764 in d08681b

} else if (!inGame && propType == typeof(string)) {

where string properties get a options button that opens a OuiModOptionString but only if not inGame. You could presumably still try to open a OuiTextEntry (=OuiModOptionString) just as you can open a SettingNumberInput...
Or is it this

Everest/Celeste.Mod.mm/Mod/Module/EverestModule.cs

Lines 721 to 722 in d08681b

	} else if ((propType == typeof(int) || propType == typeof(float)) &&
	(attribNumber = prop.GetCustomAttribute<SettingNumberInputAttribute>()) != null) {

that should be guarded against !inGame as well when there's a SettingNumberInputAttribute?

I guess that's what Snip's mentioning too, not generating the button for [SettingNumberInput] and mentioning it on the Wiki like it already is for string inputs 🤔

(Edit: Also I can't read, this is specifically about the attribute after all. Would've been nice to include the code snippet from the zip you built instead of just the binary :D)