Move away from AutoConfig

[MattSturgeon]

Background & motivation

I'm creating this issue to track & discuss a move away from AutoConfig.

AutoConfig is convenient for simple configuration because you can declare your config, add a few annotations, and watch in awe as both a frontend (GUI) and backend (save/load) is created automatically on-the-fly.

The generated GUI uses Cloth Config and the backend (in our case) is based on JanksonConfigSerializer.

It does have some limitations though:

• Widgets are limited and (mostly) chosen automatically
  • You have some control and can register your own config entry providers/transformers, but this starts to become nearly as complex as using Cloth-Config directly.
  • EDIT: This is a non-issue if you're happy to register custom providers/transformers.
• Dependencies aren't easy to add to config entries
  • You can do it using transformers though.
  • Here's another example.
• It is difficult (effectively impossible?) to have multiple instances of a config class, since each class has one ConfigHolder which is stored in a static/global dictionary.

For an example of using Cloth Config directly, one can read their demo and browse their docs.

It's also worth noting that while still maintained and actively updated to new Minecraft versions, @shedanial is no longer actively developing Cloth Config (adding new features, reviewing PRs, etc). To quote the FAQ:

Are you still maintaining Cloth / Auto Config?
Yes, but only to fix bugs and update it to new Minecraft versions
[...] Cloth / Auto Config is unlikely to receive new features.

He even notes potential alternatives, conceding that they may not be quite as good:

Here are some notable alternatives that I think (personally), are pretty good as well.

• MidnightConfig
• owo-lib
• OroConfig
• Omega Config

I still think other's config screens kinda suck - shedaniel 2022

I've considered forking cloth-config or building an alternative. The goal being to break API, cleanup old code & add new features/merge PRs. That said IDK if I realistically have time to actively maintain such a project.

Other considerations

• [Request]: allow config to be saved per server #128 Would like to be able to override config on a per-server basis (this is basically impossible with AutoConfig).
• Feature request | Server whitelist #117 Would like a config option to whitelist/blacklist servers (this is possible with basic AutoConfig features).

Evaluation

Hopefully in this issue we can discuss and evaluate the various options. My initial instinct is that we'll end up using Cloth Config.

[MattSturgeon]

Our dependency on cloth-config is one of the only things blocking us from doing snapshot builds and/or preparing releases early based on pre-releases and release candidates. We're unable to port to a new version until cloth-config has a compatible maven build published.

One solution may be to use a config system that isn't tied to any Minecraft version, and then build our own Minecraft GUI screen as a frontend.