# Data packs & resource packs Two distinct, orthogonal systems. They are kept separate and are not collapsed into one "pack" concept. The decision that data packs register through the modding API rather than a parallel path is recorded in [ADR-0007](adr/0007-declarative-content-via-modding-api.md). ## Resource packs Client-side asset overlays: textures, sounds, models, fonts, language files. No logic. A pack is a directory tree mirroring `/assets/` that overrides files by path. The renderer/asset loader resolves logical asset IDs against a stack of pack roots (base game → installed packs by priority) and the topmost hit wins. The server has no involvement. Ownership sits with the asset pipeline (in `client`, or a sibling `assets` crate if it grows). Pack authors never touch Lua. ## Data packs Declarative content definitions in JSON (or TOML/RON, TBD): blocks, items, recipes, loot tables, biomes, tags. No parallel registration system is built. The loader reads the declarative files and calls the same Lua API the engine and Lua mods use. One source of truth: ``` data/blocks/stone.json → loader → blocks.register{ id = "stone", … } ``` The loader belongs in `scripting` (or a sibling crate if it grows). Engine first-party content may use either JSON or Lua, whichever fits. Every data-pack schema is a stable contract, the same as the Lua API, version it deliberately. ## Canonical load order Later layers override earlier ones: ``` base game (assets/scripts + assets/data) → data packs (declarative content add/override) → Lua mods (full API access) → resource packs (client-only, asset overlay, always last so visuals win) ``` ## Repo layout ``` /assets/ data/ # base-game declarative content blocks/ items/ recipes/ … scripts/ # base-game Lua (behavior) textures/ models/ sounds/ icons/ shaders/ # base-game assets ``` ## User-data layout Runtime, resolved via the `directories` / `dirs` crate: ``` / mods/ # Lua mods datapacks/ # JSON content packs resourcepacks/ # asset overlays (client only) ```