Thank you for choosing to migrate your config to Fzzy Config! Re-implementation should be relatively painless for most transitions.

Migration follows of the same steps as New Configs, check out that section as needed.

General Steps

1. Update config structure
2. Refactor registration
3. Redo polish

1. Updating Config Layout ⤴

The majority of config libraries work with Plain Old Java (Kotlin) Objects. If your previous library was one of those your config structure is already done! Fzzy Config also works with POJO. In step 3 you can look at how to take a simple config to the next level.

To prepare your config class for use with Fzzy Config, you will need to extend Config 🗗. This defines registration information as well as provides various helper methods.

An example conversion from Cloth/Auto Config:

// before
@Config(name = "general")
public class GeneralConfig implements ConfigData { /* implementation */ }

// after
public class GeneralConfig extends Config { 
    public GeneralConfig() {
        super(Identifier.of(MOD_ID, "general"));
    }
    /* implementation */
}

For a config managed by GSON or similar, simply extend Config where before the object was entirely plain.

For an in-depth look at laying out a config and more advanced options you can consider check out:

Laying out Configs

2. Refactor Registration ⤴

Fzzy Config has an inline registration system that works with an INSTANCE pattern. Configs are registered and loaded in one method call, meaning that config instantiation is lock-step with registering it and deserializing its info from file. This prevents any worry about load order, as any call to the instance will guarantee it is registered and loaded first when the instance initializes.

//instance of your config loaded from file and automatically registered to the SyncedConfigRegistry and ClientConfigRegistry
//Pass in a RegisterType if you want to register it in specific places
public static MyConfig myConfig = ConfigApi.registerAndLoadConfig(MyConfig::new);

Fzzy Config won't "deserialize in place", as it needs access to instances of the config class. Loading and storing a config managed this way is easy with a Config/Impl pair or an INSTANCE pattern.

/* Configs/Impl pair */

// access you config data here
public class Configs {
    public static MyConfig myConfig = ConfigApi.registerAndLoadConfig(MyConfig::new);
}

//create the config "template" here
public class MyConfig extends Config { /*implementation*/ }

/* Instance pattern */

class MyConfig extends Config { 
    //constructor here

    // instance your config for access in a static field
    public static MyConfig INSTANCE = ConfigApi.registerAndLoadConfig(MyConfig::new);
	
	/*implementation*/
}

3. Redo Polish ⤴

The features that came with the past library (annotations, translations, etc.) won't work with Fzzy Config. Fzzy Config has options of its own to replace them.

Translation

Used something like @ConfigEntry.Gui.Tooltip from Cloth before? No need with Fzzy Config. All pieces of a config are translatable and describable by default. Check out the translations guide to learn more:

➡️ Translation

Validation

Fzzy Config has many validation options. Validation is a foundation of its functionality! Whether you utilize these tools purposefully or not, Fzzy Config will apply them in the background to keep everything running smoothly.

➡️ Validation

Annotations

Fzzy Config has a suite of Annotations to add the depth of function you need to your refactored config.

➡️ Annotations