AutoConfig-TOML

A custom TOML ConfigSerializer
for AutoConfig that uses
NightConfig.

AutoConfig-TOML does not require Fabric API!

Sponsor

I've partnered with Apex Hosting! In my experience, their servers are lag-free, easy to manage,
and of high quality. Check them out here:

Aims

AutoConfig-TOML aims to provide a ConfigSerializer for TOML that is slightly better than
Toml4jConfigSerializer,
the TOML ConfigSerializer that comes with AutoConfig.

Features

Better validation

• ConfigData#validatePostLoad() is always called and any updated values are written to disk on
  both serialization and deserialization.
• As a result, it can be ensured that valid values are always present both in the configuration
  written to disk and in the configuration object.
• Additionally, ConfigData#validatePostLoad() is also called on categories, and not just the main
  configuration object.
• In addition, NightConfig's Spec*
  annotations are supported, and invalid values are automatically reset to the defaults.

Property keys

• Property field names are automatically converted to lower_snake_case TOML keys.
• Path
  annotations may be utilised to manually specify TOML property keys, which are not subject to this conversion.

Configuration paths

• A Path annotation may also be used to specify the path of a configuration file relative to the
  configuration directory.

Comments

• Comments for properties, categories and configuration files may be specified through the use of
  TOMLConfigSerializer.Comment.
• Default, minimum and maximum values are automatically appended to the comments.

Utility methods

If a reference to the TOMLConfigSerializer is stored, the following utility methods are
available:

• TOMLConfigSerializer#getConfig() returns the configuration object.
• TOMLConfigSerializer#reloadFromDisk() reloads the configuration from disk.

Usage

TOMLConfigSerializer can be used just like any other ConfigSerializer for AutoConfig.
Example usage can be found in the test mod.

Using with Gradle

repositories {
	//...

	maven {
		url "https://dl.bintray.com/shedaniel/cloth-config-2"
	}

	maven {
		url "https://dl.bintray.com/shedaniel/autoconfig1u"
	}

	maven {
		url "https://jitpack.io"
	}
}

dependencies {
	//...

	modImplementation("me.shedaniel.cloth:config-2:${project.clothConfigVersion}") {
		exclude(module: "fabric-api")
	}
	include "me.shedaniel.cloth:config-2:${project.clothConfigVersion}"

	modImplementation("me.sargunvohra.mcmods:autoconfig1u:${project.autoConfigVersion}") {
		exclude(module: "fabric-api")
	}

	include "me.sargunvohra.mcmods:autoconfig1u:${project.autoConfigVersion}"

	modImplementation "com.github.TheRandomLabs:AutoConfig-TOML:autoconfig-3.x.x-fabric-SNAPSHOT"
	include "com.github.TheRandomLabs.AutoConfig-TOML:autoconfig-3.x.x-fabric-SNAPSHOT"
}

Why not just write another configuration library?

• AutoConfig lets me easily create a configuration GUI on both Fabric and Forge.
• I'm not sure the world needs yet another configuration library.
• This way, I don't have to maintain my own configuration library.