rivencraft/docs/AGE_PROFILES.md

Age runtime profiles

Rivencraft loads Age runtime profiles from server data packs at data/<namespace>/rivencraft/age_profiles/<name>.json. The resulting profile ID is <namespace>:<name>. Profiles select registered world-generation resources; they do not contain an Age's seed, name, spawn, or rolled traits.

Schema version 1

{
  "schema_version": 1,
  "terrain": "noise",
  "noise_settings": "minecraft:overworld",
  "biome_preset": "minecraft:overworld",
  "dimension_type": "minecraft:overworld"
}

terrain is noise, flat, or void. Noise profiles require noise_settings and biome_preset references. Every profile requires a dimension_type reference. Omitted resource references use the Overworld entry. Rivencraft validates all referenced entries against the loaded dynamic registries during data-pack reload. An invalid profile is rejected.

The built-in profile IDs are rivencraft:standard, amplified, island, cave, flat, and void. Their JSON files are ordinary built-in data-pack resources and can be overridden by a higher-priority pack. The example under docs/example-age-profile-pack can be copied into a world's datapacks directory. Valid custom profiles join the stable, sorted pool used when a new Age rolls its base terrain; the selected ID is then persisted with that Age.

Persistence and reload behavior

An Age permanently stores its selected profile ID, generation version, seed, and rolled traits. /reload replaces the profile definitions but does not reroll those immutable values. An unloaded Age resolves its stored profile again when it loads, so intentional profile overrides affect its runtime resources and newly generated chunks.

A profile removed after an Age was created resolves to rivencraft:standard. The legacy rivencraft:random_vanilla alias also resolves to standard. Rivencraft logs this fallback. Invalid built-in overrides do not replace the required built-in definitions; a reload fails if a required built-in profile is absent after resource resolution.

Only schema version 1 is accepted. A future schema change must add an explicit migration path before incrementing the version. The saved Age generation version remains independent of this data-pack schema and is never silently rewritten.