Skip to content
Introduction

Introduction

PKL  pronounced “Pickle” -  is a embeddable and modern configuration language by Apple, which pkl4mc brings to Minecraft. You can write, datapacks, recipes, worldgen and mod configs in a typed language with autocomplete, comments, variables and reuse, while pkl4mc just evaluates them to the JSON, which Minecraft anyways already uses.

This was originally a dumb idea I had and built for self use and to learn more about PKL runtime and JVM.

Why not just JSON?

JSON has no variables, no comments, no types, and no reuse. A typo in a field name fails silently and you will find it out when your loot table drops nothing or your ore doesn’t generate :(

Shoutout to Packs Editor btw, which tackles this issue a bit differently. Instead it adds a fully fledged IDE alongside your game, if this is also a option for you :)

To give you a little example on how JSON actually translates to PKL in pkl4mc:

A smelting recipe in JSON:

{
  "type": "minecraft:smelting",
  "category": "misc",
  "ingredient": { "item": "minecraft:sea_pickle" },
  "result": "nothingcore:cooked_sea_pickle",
  "experience": 0.7,
  "cookingtime": 200
}

The same recipe in PKL, using the bundled recipe schema:

amends "@pkl4mc/recipes.pkl"

smelting {
  new {
    name = "cooked_sea_pickle"
    category = "misc"
    input { item = "minecraft:sea_pickle" }
    output { item = "nothingcore:cooked_sea_pickle" }
    experience = 0.7
    cookingTime = 200
  }
}

When you misspell something, then the editor flags it before you even reload:

Editor flagging a misspelled field as you type

What pkl4mc can do

Virtual datapacks

You can put .pkl files in config/pkl4mc/data/ and they get evaluated and injected into the data system on world load. Reload them with /pkl reload on runtime.

Typed schemas

pkl4mc serves out of the box schemas for vanilla formats (recipes, loot tables, tags, worldgen) and some (currently 35) mods. You can check out all in the schema catalog.

Autocompletion with ids

The /pkl dump command exports every registry id of your running modpack, so item, tag and fluids just autocomplete and validate.

Conditional content

Files can branch on which mods are loaded, so one pack works across modpack variants.

Mod configs in PKL

Although that’s kind of a gimmick, as a mod developer you can create configs through the config API. I mean, why not.

What pkl4mc can NOT do

No imperative scripting

PKL is a configuration language, not a scripting engine. There are no event handlers, no callbacks, no KubeJS-style “on block break, do X”. If a feature needs code to run at game time, it needs a mod.

Vanilla value overrides (yet)

Vanilla or mod value overrides like replacing the vanilla noise router without stomping other mods (LOL) are on the roadmap.

No client-side gameplay (yet)

Client support is hard limited currently to EMI support, such as index changing or recipe hiding.

No registry-frozen content without restart

Some integrations, like Totemic instruments or totem carvings register at mod load sadly :( These ones would need a game restart.

Who is pkl4mc for?

Probably for modpack and datapack devs, who wanna have autocompletion and typechecking instead of guessing, or maybe hate JSON for some reason (a camp I’m in too).

For modpack devs with companion mods, who just want a better workflow for recipe adjustments and unifications (another camp I’m in too).

Also for mod devs who wanna depend on pkl4mc as a library and load typed configs via PklConfig.load<T>() or register their own schemas (You can guess it).