A brainstorm of Fabric Config schema and behavior

config-meanderings.md

Config categories (environments?)

• Prelaunch, for configuring mixin plugins (immutable)
• Instance, for configuring registration and other things that happen at load time (immutable)
• Server, for things that control server-side behavior (mutable)
• Client, for client side behavior (mutable)

Config Schema

• Defined in mod root
• Version flagged (in case more types or constraints are added)
  • Config value types and constraints are likely locked down
• External tools can read from the config schema
• Fabric Config API generates config files from the schema
• Tools take localizations from the mod's language files

Config Schema Format (tentative)

{
 "version": 1,
 "values": [
   {
     "name": "my_option",
     "type": "identifier",
     "ingameType": "registry/minecraft:block", // better names for this?
     "category": "server",
     "defaultValue": "minecraft:air",
     "constraints": []
   }
 ]
}

Config value types

• integral (int, long)
• floating point (double)
• boolean
• string
• enum
• Identifier
• registry entry (Block, Item, Biome, etc.)
  • tag support?
• list of record

File format potentials

• JSON with __comment keys
• Jankson
• JSONC Only a single config file format should be supported, for ease of use by external tools

Config reloading

• Add a way to reload a config from disk
  • Potential: /reload for server, F3+T for client
• In-game config value changing
• Callbacks that are run when a value changes (any way)
  • (old, new) -> { ... }
  • (null, new) on initial load?