Migrate the client configs

[ferriarnus]

Moving the client settings to the same system as the server configs

[Techjar]

What about all the existing GUIs with localized tooltips? And what about everyone's existing options files? I dunno, this just kinda seems like a "if it ain't broke don't fix it" situation.

[ferriarnus]

I somewhat agree with you that working stuff should be left alone, however, having multiple systems for configs is a bit annoying. I've not looked into migrating the old ones, as I'm unsure if it's a big issue. For the guis, same as before: There's nothing really wrong with them, but multiple systems is hard to maintain.

[fayer3]

we can convert the old guis to use the new config system

[Techjar]

I guess I'll just be sad to see my VRSettings framework go away. I spent a lot of time refactoring it into an easy-to-work-with state. (You guys should have seen the old system lmao)

[ferriarnus]

Yeah I get that, but I feel that toml is a bit of a nicer format (and is used by other mods so users will be familiar with it). I'm not a big fan of the massive enum, and annotations made it a bit more complex then needed imo. But the gui's can stay yeah. It's just that I wanted the server and client configs to have the same backend (and one which was hopefully less complex)

[fayer3]

yeah, we can keep the gui for now

[Techjar]

Yeah I don't think mod menu is as organized or user-friendly for the amount of settings we have, so at least keeping the GUI is kind of necessary. We'll have to convert all the localization strings though.

[Techjar]

annotations made it a bit more complex then needed imo

The reason for annotations was to avoid having to use getIntValue() or whatever all over the place. It can be used as just a regular field with the actual type. I'm still not a fan of the Fabric config system for that reason.