update use textComponents, since we rely on paper anyway

[FireInstall]

Minedown instead of MiniMessage

[Phoenix616]

Does this actually do anything on its own? I would assume this needs the config to be saved afterwards. (And you wouldn't want that on loading as that would overwrite existing values) Also with the removed saveDefaultConfig I would assume that it doesn't initially save the config at all.

I don't think it really matters that much that the keys are in the config though. If they are missing they will be pulled in from the file in the jar and if someone with a config which is missing them wants to edit it they can just get the ones they want from the default file in the jar or on github.

[FireInstall]

Well yes, it was missing the call to saveConfig(). That was the point where I lacked enough concentration to go to sleep.

However, in my opinion it is pretty inconvenient and confusing, for the config file to miss newly added stuff, when it is really no effort to save defaults.

[Phoenix616]

This will now cause your local file changes to be overwritten when running /syncinv reload as that calls loadConfig too. The only way to avoid that while still writing the new values into the config would be to first save the default config, then reload the config and then save the defaults into it again. (Or do the defaults saving in startup outside the loadConfig)

[FireInstall]

We could just use the config in jar, if we don't overwrite the defaults in getLang() (would be also a problem if we would not save new config keys to disk).
In this case we just have to reload and save.