configkit

ConfigKit gives Vintage Story mods an in-game settings screen, drawn with the game's own interface. No Dear ImGui, and nothing extra to install alongside it.

It reads the same configlib-patches.json files mods already ship and writes a plain ModConfig/<mod>.yaml you can edit by hand, so a content mod needs no changes at all, and no dependency on this library either. If ConfigKit isn't installed, a mod simply falls back to the default values in its own assets.

Tested in-game across singleplayer, real two-process multiplayer, and a run alongside another config mod. Verified against a 95-mod pack: every asset it patches resolves identically to configlib's output.

For players

• Press P, or use the Mod settings button in the pause menu.
• Settings the server controls are shown read-only unless you have controlserver.
• Edit a file in ModConfig/ while the game is running and it reloads on the spot.
• Type in the filter box beside the mod dropdown to find a setting by name, wherever it lives.
• Don't install ConfigKit and configlib together. If ConfigKit sees configlib or autoconfiglib it stands down and says so in the log, so nothing breaks, but only one of them can manage your configs. Config managers that only handle some mods are a different matter: name a mod under UnmanagedDomains in ModConfig/configkit.json and ConfigKit leaves that one alone without switching itself off.
• You can join a server that doesn't have it, and you keep your own settings screen for client-side mods.
• A server running it needs its players to have it too. Anyone without it is turned away on the connect screen and offered the download, the same as any other server-side mod.

For server admins

Settings can rewrite values inside other mods' JSON assets (block behaviour, recipes, item stats) from one config file, without repacking anything. That is often the quickest way to retune a pack for a server, and the server's values are synced to every client on join.

For mod authors

Most mods need no changes. The migration guide covers four cases:

• Ships a configlib-patches.json and no C#? Nothing to do.
• Checks whether a config mod is installed? One line.
• Calls into the library? Swap a reference and rebuild.
• Draws its own ImGui settings screen? Describe the settings instead, usually less code than you had.

A settings class needs only stock .NET attributes ([Description], [Range], [Category]), so it keeps no reference to ConfigKit and still compiles and runs without it. Nested classes, dictionaries and lists render themselves — a sub-object becomes a foldable section, a dictionary opens a screen of its own with a filter and an Add button, and neither needs a line of UI code.

It also reads what your class already carries: your /// doc comments become the tooltips, [DisplayFormat] decides how a number reads, validation attributes are enforced with the messages you wrote — including your own ValidationAttribute — and a nullable value type keeps its null instead of showing it as zero.

Full guides are linked under Documentation, just below.

Documentation

All of it lives in the repository, so it stays with the code it describes:

• Structured config — what each shape becomes on screen: nested classes, dictionaries, lists, and every attribute that steers them. With screenshots.
• Integrating — the API, when your values are actually there, client and server, and what to look at when a setting does not appear.
• The config file format — settings, patches, JSON paths and expressions, for a mod with no C# at all.
• Migrating from configlib — four cases, and most mods fall into the one that needs no work.
• Compatibility — a survey of the 2,000 most-downloaded 1.22 mods, sorted by what each would have to change.
• What changed from configlib — the deliberate differences, what was added, and the bugs fixed on the way.

Verifying what you downloaded

Every release is built by GitHub Actions and carries Sigstore-signed provenance tying the zip to the commit that produced it:

<pre>gh attestation verify configkit_&lt;version&gt;.zip --repo dizzyd/configkit</pre>

The build also refuses to package anything questionable: it asserts that ConfigKit.dll declares only its own types (dependencies ship as separate files and are never merged in), that every third-party dll matches its publisher's SHA-256, and that each one ships with its licence. What that proves is provenance: the binary contains what the source says, not that the behaviour is correct. The source is short; read it.

Origin, and credit