Configly

Mod-wide configuration for Hytale mods. A library for mod developers.

Configly is infrastructure for your mod, not something your users install. You shade it into your jar, define your config, and ship. Your users never learn the name Configly - they just get a clean, editable config file where they expect one.

The problem

Giving your mod a config file today means registering your own AssetStore. That gets you:

A whole asset folder holding a single file, Server/YourMod/Config/YourMod.json
An asset class, a codec, a key function, and store registration written by hand
No way for anyone else to override a value without replacing the entire file

And every mod that does this puts its settings somewhere different, so a server owner running twelve mods hunts through twelve layouts.

What Configly does

Registers the store once, for every mod. You write the codec for your own fields and nothing else. Every mod's config lands in one shared Server/Configs/ folder, one file each.

Server/Configs/
├── Hexcode.json
├── Icarus.json
└── YourMod.json

Integration

Define your config. Extend Config, give it a BuilderCodec, and write it exactly like any other Hytale asset codec:

public final class HexcodeConfig extends Config {
    public static final BuilderCodec<HexcodeConfig> CODEC = BuilderCodec.builder(HexcodeConfig.class, HexcodeConfig::new)
        .append(new KeyedCodec<>("RespectPvp", Codec.BOOLEAN),
            (config, b) -> config.respectPvp = b,
            config -> config.respectPvp)
        .documentation("Whether Hexcode spells honour the server PVP setting")
        .add()
        .build();

    private boolean respectPvp = true;

    public boolean respectsPvp() {
        return respectPvp;
    }
}

Configly.register("Hexcode", HexcodeConfig.class, HexcodeConfig.CODEC);

Ship the default at Server/Configs/Hexcode.json:

{
  "Type": "Hexcode",
  "RespectPVP": true
}

Read it anywhere:

HexcodeConfig.get().respectsPvp();

That is the whole integration.

What you get

Any shape you want. Your codec, your fields, your validation. Configly never inspects your config, so it can be as simple as one flag or as deep as a nested balance table.

Typed asset editor support, free. Every field becomes a real editor control and every .documentation(...) string becomes its description. Your users stop guessing at raw JSON, and you stop fielding "what does this value do" reports.

Hot reload. Edits from disk or the asset editor take effect without a restart.

Patchable by other packs. A compatibility pack can override a single value of your config without touching your mod, gated on your mod being installed:

Server/Configs/Hexcode.patch

{
  "$Requires": "Riprod:Hexcode",
  "RespectPVP": false
}

Everything the patch does not name keeps your value. Requires Patchly; Configly works fine without it.

Uninstall-safe. If your mod is removed, its config file is left byte-for-byte intact rather than erroring. Reinstall and every tuned value and third-party patch is still there.

Shipping it

Two options: You can either put a Configly.jar into lib/ and locally shade it or reference Configly from the maven repo

plugins {
    id 'com.gradleup.shadow' version '9.4.2'
}

configurations {
    shadowBundle
    implementation.extendsFrom(shadowBundle)
}

dependencies {
    shadowBundle(files('lib/Configly-X.Y.Z.jar'))
    // or shadowBundle('curse.maven:configly-1640076:8580658')
}

shadowJar {
    archiveClassifier.set('')
    mergeServiceFiles()
    configurations = [project.configurations.shadowBundle]
}

tasks.build {
    dependsOn("shadowJar")
}

Your mod ships alone. No required dependency, nothing for your users to install.

Bundling is safe. Any number of mods can each carry their own shaded copy. At startup one registers the store and the rest bind to it, so copies never collide and never fight over the folder.

Docs and source: https://github.com/itsriprod/configly Issues: https://github.com/itsriprod/configly/issues License: GPLv3