I think Forge Config API Port is a great mod (along with other config API mods), however I'd like to not depend on a config API. ImmersiveMC's config is relatively simple, so I think it'd be worth it to write my own config implementation, or just use nightconfig.

As an aside, this is lower priority in comparison to other 1.5.0 issues, since this is a system that already works well.

Sitting on this, I may switch to a different config system in the future, however rolling my own would be large undertaking that, as of writing, I don't feel like doing. Likely won't be getting to this issue anytime soon.

Merged into 1.20.4 as 4a238a1. Still need to do other Minecraft versions:

• 1.20.2 (3f2c5ec)
• 1.20.1 (d194eb2)
• 1.19.4 (5cfd4c9)
• 1.19.3 (0f31427)
• 1.19.2 (c4c5f29)
• 1.18.2 (f8be5a8)

Due to #444, this is getting pushed up a good amount in prioritization.

Going to look into utilizing GSON here, since it has been packaged with Minecraft for a long while, iirc.

EDIT: GSON looks to be a good idea. We can simply serialize/deserialize the ActiveConfig class directly, though we'd have to update the defaults in ActiveConfig to be the actual defaults of the mod. Since super classes are covered, any client-only configuration can be done in a ClientActiveConfig. Despite the name though, this will go in common, since the server will inevitably want it for things, such as future bag coloring. The only catch is the configuration text file will no longer provide descriptions, but I feel this is okay; the names are descriptive enough as-is in most cases, and the in-game configuration screen will still have them, so this only hits server admins. As a last resort, we can ask users to customize in-game, then export the config to their server, like with #444, or we can allow editing the server config while in-game directly (honestly seems like a good idea).

We'll need to write an adapter to load values from the old config system, which obviously shouldn't rely on Forge Config API Port. I think it's best to just write this functionality directly, since it's a one time movement to the new system. I'll just have a map of key names to functions that update fields, which can then be run on the file, looking for the key=value (with some number of spaces before and after the =) and converting accordingly.

Lastly, post-deserialization, we'll need to go in and verify all values are legitimate (ints fall into valid ranges, etc.)

Work for this is being done in the config-refactor branch. In terms of this issue, work is far along.

What's left:

• Ensure all values are in valid ranges
• Converter from the old to new format
• Give all the config entries consistent names in the JSON
• Much more testing

Done and done!