Minecraft Blogs / Tutorial

Function Data Packs for Dummies #11 Part 1 | The return of JSON: Introduction & Wiki Pages

  • 2,511 views, 7 today
  • 19
  • 7
  • 3
Bertiecrafter's Avatar Bertiecrafter
Retired Moderator
Level 70 : Legendary Engineer
This series of tutorials will teach you how to create your very own data packs, assuming you know absolutely nothing about commands. Although data packs could just contain files that replace built-in assets like resource packs, these posts will focus on adding new features and mechanics to the game. In every part I assume you've read the previous parts.


All the way back in part 2, you were introduced to JSON. Since then, I'm sure you noticed you've been seeing it everywhere in pack.mcmeta, function tag files and the JSON text component (which is used in /tellraw for example). We also took a deep dive into NBT, a format that looks like JSON but with a lot more distinguished types and no requirement of using quotes for object keys. If it has been a while since you touched JSON, have a look at Part 2. If you can't remember how JSON is different from NBT, view the comparison examples in Part 10.1.


In this tutorial I'm not going to talk about how you can use an online generator to generate recipes, advancements, etc. using an easy to use interface. I don't like using generators, because then you'd be at the mercy of how much the developer of that generator cared to implement. Writing JSON yourself straight from the wiki pages isn't difficult, takes roughly as much time as configuring the web page and often allows for way more customization.

I'll be discussing each of the different text files (resources) that weren't covered yet and where to find their JSON structure. Keep in mind that the "namespaced identifier" of any resource is "<namespace>:[​path/]<​name>", similar to how function files are located. The same placeholders will be used in the path specified below each resource type. If you place a resource at the same relative path as it's located in the .minecraft/versions/<version>/<version>.jar, you can overwrite resources.

This part will be purely theoretical, with the next part being an in-depth walkthrough.


Advancements show up as a tree in the advancement GUI (I'm sure we all know it). They track conditions and when each of the criteria is met they can give experience, give loot, unlock recipes or execute functions. Besides being great for story lines, they are also a more efficient alternative to a scoreboard objective that is checked every tick. They also provide unique triggers that are impossible or very difficult to detect otherwise. To apply advancements as a reusable detector, make the advancement "reward" a function that uses /advancement to revoke itself. That way it can be triggered again. For non-technical usage (for story telling in adventure maps), there are plenty of ways to customize the display of advancements. You can create your own tab, choose a background, icon, frame type, whether or not a toast pops up in the top right corner and whether or not it's announced in chat. Since the title and description use the JSON text component, you can make them look really pretty.

You can find the JSON structure for advancements here.
Advancements are located at "data/<namespace>/advancements/[​path/]<​name>.json" inside a data pack.

Loot Tables

Loot tables are all about item generation. They're used to generate chest and mob death loot by chance according to certain conditions and functions. Mobs have "DeathLootTable" and "DeathLootTableSeed" NBT keys of which the string values defines the loot table to use upon death. Chests and other containers have "LootTable" and "LootTableSeed" NBT keys of which the string values define the loot table used to fill the container with items next time it's opened. A "seed" is an optional string of your choice that locks the values picked during randomization in place. That means that loot will be random and predictable at the same time, comparable to the world generation seed. The in-depth control and ability to apply logic, makes loot tables also a good choice to use with the "/loot" command to generate item sets on demand.

You can find the JSON structure for loot tables here.
Advancements are located at "data/<namespace>/loot_tables/[​path/]<​name>.json" inside a data pack.


Predicates are files that represent certain conditions. They can be used with the "/execute if predicate" instruction or the "@x[​predicate=...]" target selector argument. While the technical usage of advancements can be seen as an extension to scoreboard objectives, the usage of predicates can be seen as an extension to target selector arguments. They are an excellent choice if you want to filter by a certain state, but don't want that to be your entry point. Advancements can do everything predicates can, but advancements are always the start of the command, while a predicate can function as a filter mid-way.

You can find the JSON structure for predicates here.
Predicates are located at "data/[<namespace>/predicates/[​path/]<name>.json" inside a data pack.


Recipes are used to define patterns of items and their resulting item when put into a crafting table, furnace or one of the other blocks supporting recipes. Recipes can't have custom NBT (yet), so a common technique is to make it result in a knowledge book which is an unobtainable item in survival and most likely worthless. Then an advancement can detect the player unlocking the recipe by crafting it and call a function. The function then revokes the recipe (using /recipe) and advancement, clears the knowledge book and gives the player the item with custom NBT that should have been the actual result of crafting. The downside is that the recipe can't show up in the recipes GUI since it relies on the "unlock" event that's caused by crafting. If you do not need custom NBT on items and you're not replacing a vanilla recipe file, I recommend creating an advancement with the "minecraft:tick" trigger to unlock the recipe. That way the recipe shows up in the crafting table.

You can find the JSON structure for recipes here.
Predicates are located at "data/<namespace>/recipes/[​path/]<​name>.json" inside a data pack.


This is the easiest JSON syntax and it's just used to group items, entities, blocks or functions. There are many places they can be used and you target tags by simply using the namespace identifier of the tag with a # in front. So for example, "/function #bertiecrafter:my_functions" runs all the functions in that tag. Also "/clear @s #bertiecrafter:forbidden_items" will clear any item that is listed in that tag.

You can find the JSON structure and relative paths for tags here.


We all know what a dimension is, but the amount of configurable settings for a dimension is actually insane. Way too much to cover in this blog post. In general, a new dimension starts with a "dimension file". Inside you'll at some point define the dimension type. You can choose a string preset, define a JSON compound right there or create a "dimension type" file. Same goes for the individual world gen components, either choose an existing value or create your own in a custom file. The amount of files and data might seem daunting at first, but remember that you only have to define the data if a preset does not fit your requirements. You can start with small adjustments and a simple dimension file, look at the other JSON structures when you get to them. Tp to your custom dimension using "/execute in <dimension> run tp @s ~ ~ ~".

You can find the JSON structure for dimensions here.
Dimensions are located at "data/<namespace>/dimension/[​path/]<​name>.json" inside a data pack.

Other customizable components referenced by dimension files.
Dimension type JSON at "data/<namespace>/dimension_type/[​path/]<​name>.json"
Biomes and other world generation components JSON. Consult the wiki page on data pack layout for info on their location.

Challenge Yourself

After every tutorial, I'll include a section where you are challenged to apply what you've learned. I recommend you playing with what you've learned, it helps you getting familiar with new concepts and be able to find solutions to problems. You don't have to do exactly what's written below, you can always challenge yourself in a different way.

Pick one of the JSON file types above (not Tags) and create one for your data pack from scratch, just using your editor and the wiki pages. Use Part 2 if you don't fully remember how to write JSON. If you can't come up with anything, create an advancement that defines a background + tab icon and triggers when a block of stone is mined. It should call a reward function that gives the player a diamond with the name "Lucky Charm". If you want to create a second advancement, use the "parent" JSON key to link it to the first advancement and start building your own advancement tree.

What's next?

The next tutorial is going to be an in-depth walkthrough visiting several of these JSON files. See you then! =)

Subscribe if you want to get notified of new posts.

Function Data Packs for Dummies #11 Part 1 | The return of JSON: Introduction &amp; Wiki Pages
Function Data Packs for Dummies #11 Part 1 | The return of JSON: Introduction &amp; Wiki Pages

Create an account or sign in to comment.

11/14/2020 1:26 pmhistory
Level 70 : Legendary Engineer
Bertiecrafter's Avatar
Thank you FishStacks, Luracasmus, Redfuzzyturtle, pettyGamingHD, Eynnom, DinoDesmond, BravePeas, PMC, Dhaloh, Chimerabot, Vellaris, TheBigPug, TofuChild27, Yellowglacier, Sir_Wodr, MSHuman and SUPERIONtheKnight for the diamonds!
01/24/2021 1:06 pm
Level 38 : Artisan Pixel Painter
Dunk__'s Avatar
a bot?
01/24/2021 3:12 pmhistory
Level 70 : Legendary Engineer
Bertiecrafter's Avatar
Nope, all hand written (or I guess typed and sometimes copy pasted if you diamonded a lot). It's the least I can do for your support =)
Planet Minecraft


© 2010 - 2024