Datapacks

Server data lives in two places under config/pkl4mc/. Both are injected as a virtual datapack on world load and reload with the reload command.

data/ (loose files)

Loose .pkl files, KubeJS-style. No pack.mcmeta, no zip, just files. The path under data/ is the resource location:

This maps to mypack:recipes/steel (.json). Namespace comes from the first folder. Everything after maps 1:1, .pkl to .json.

datapacks/ (full packs)

Full datapacks with .pkl files inside, same structure as vanilla world/datapacks/. Use this format for self-contained, shareable packs.

mypack/ is a folder pack, mypack.zip is a zip pack with the same layout inside.

Zip packs re-open on file change, so replacing the zip and reloading picks up the new version without a restart.

Both support every schema and behavior identically.

One file, many outputs

Multi-recipe schemas render each entry as its own JSON file, named by its name field. One .pkl file with twenty recipes serves twenty recipe files. A file whose output ends up empty (for example, every entry behind a false mod condition) serves nothing instead of erroring.

Special folders

• data/<namespace>/recipe_removals/ holds recipe removal rules. Files there are applied at recipe load instead of being served as datapack content.
• config/pkl4mc/assets/ serves client resources, such as EMI customization. Client assets reload with F3+T, not /pkl reload.

The edit loop

Edit, run /pkl reload, test. Changed files are re-evaluated, unchanged files stay cached. Errors never crash the game: broken files are skipped and reported by the errors command.