SuperMartijn642s Config Lib FAQ

Add Config Lib as a dependency in your mod's build file, then create a config builder in your mod's initialization code. Register the config with the builder so Config Lib can handle loading, syncing, and reloading for you.

Use the config builder to define your config, then add entries like booleans, integers, strings, or lists with their default values and comments. Call the builder's register method so Config Lib generates the file and manages it.

Common configs exist on both sides and are usually synced, client configs only affect the client, and server configs only exist on the server. Config Lib generates the right file for each type automatically, so you don't have to handle that yourself.

When you mark a config as synced, Config Lib sends the server's values to connecting clients so they match. Clients use the synced values instead of their local file, which prevents desync issues in multiplayer.

The most common cause is forgetting to register the config as synced, or registering it on only one side. Make sure the config is registered during common setup and that the synced flag is set on the builder.

Config Lib watches the config file and reloads values when it changes, so editing and saving the file is usually enough. You can also trigger a reload through the mod's own reload command or keybind if it provides one.

This usually happens when the config is registered too late or in the wrong place, so Config Lib can't track it properly. Register your config during your mod's common initialization before any world loads.

Yes, Config Lib supports server-only configs that live on the server and aren't sent to clients. Register the config as server-side so it generates and loads only where it's needed.

Config Lib is a library other mods depend on, so it generally coexists fine with other config systems. Conflicts are rare and usually come from two mods trying to manage the same file, not from Config Lib itself.

Config Lib is lightweight and only reads values when needed, so it has negligible impact on performance. Reloading happens on file changes rather than every tick, so it won't cause ongoing lag.

In your mod's code, build a ConfigBuilder, add your options with the provided value types, and call the build method with a name and a path. Config Lib then creates the file and handles loading, saving, and syncing automatically.

It writes them to the standard config folder for your mod loader, typically inside a folder named after your mod. The exact path is determined by the name and directory you pass when building the config.

Mark the option as a server config rather than a client config when registering it. Server values are read from the server's file and synced to connected clients, so all players see the same setting.

This usually happens when the value is edited while the game is running without triggering a save, or when a server config is changed on the client side where it has no effect. Edit the correct file for the config type and reload or restart so the change is picked up.

Yes, Config Lib supports reloading values between world loads and can apply changes without a full restart. Some options may still require a world reload or rejoin to take effect depending on how the mod reads them.

Open the config file in a text editor, change the values while keeping the existing structure and keys intact, then save. Config Lib will read the updated file the next time it loads or reloads the config.

Yes, it is designed to run on both sides and handles syncing values between them. Server-side values are authoritative and get sent to clients so everyone stays consistent.

No, it is a lightweight library focused on config handling and does not add ongoing per-tick overhead. Any performance impact comes from the mods using it, not from the config system itself.

Yes, any mod that depends on Config Lib requires it on both sides, since the library handles loading and syncing on client and server. Missing it on either side will prevent those mods from working.