Content Packs

Documentation baseline: VoxelCore main at 452b569 · 14 September 2026.
Repository: https://github.com/VoxelHorizons/VoxelCore

VoxelCore discovers self-contained content packs under plugins/VoxelCore/content/.

Layout

plugins/VoxelCore/content/
└── <pack-directory>/
    ├── pack.yml
    ├── content/
    │   └── **/*.yml
    └── assets/
        └── <namespace>/
            ├── models/
            ├── textures/
            ├── font/
            └── sounds/

The pack directory name is organisational. Identity comes from the manifest namespace and keys in the content files.

content/ is scanned recursively for .yml/.yaml definitions in deterministic order, so authors can create arbitrarily useful nested organisational folders without changing ContentIDs.

`pack.yml`

schema: 1
namespace: mypack
dependencies:
  - shared
  - core

Supported manifest keys are schema, namespace, and optional dependencies. Unknown or malformed keys are rejected rather than silently ignored.

Namespaces and dependencies

Each pack namespace must be unique. A pack may always reference:

its own namespace;
Minecraft resources where valid.

A cross-pack parent or model reference requires the referenced namespace to be declared in dependencies. Missing dependencies and duplicate namespaces fail loading.

YAML safety and strictness

The loader uses bounded SnakeYAML parsing, rejects duplicate YAML keys, applies alias/document limits, validates expected scalar/list/map types, and rejects unknown top-level/item/render fields. This deliberately turns authoring mistakes into actionable load errors instead of ignored configuration.

Assets

Authored assets live beneath the pack's namespace. For example:

render:
  model: mypack:item/ruby

maps to:

assets/mypack/models/item/ruby.json

Generated Minecraft override/item-definition glue belongs to compiler output, not authored content.

Continue with Products/Voxel-Horizons/VoxelCore/Item-Authoring and Products/Voxel-Horizons/VoxelCore/Rendering-and-Models.