Datapacks aren’t a good method of modding
Minecraft keeps pushing in the direction of datapacks. I don’t like it.
Editor support is poor
They’re JSON files, which are notoriously picky syntax-wise. A fancy editor can help, but datapacks are aimed at nonprogrammers, who probably don’t have a fancy editor.
Even if the file is syntactically valid, you have to hope it adheres to the correct schema. Frequently the schema is undocumented.
Not a very friendly environment to throw people into.
Debuggability is poor
Why is your JSON file not being loaded?
- Is it in the wrong place?
- Is the datapack containing it disabled?
- Is there a syntax error in that file?
- Is there a syntax error in another file, which if corrected would load the file you want?
- Is an error in a completely unrelated file causing some code in Minecraft to give up before loading your file?
- Is something in another datapack overriding your file?
Who knows! You aren’t given the tools to even start debugging this.
Datapacks are not actually composable
The dream is that you can add ten datapacks and they all act independently. This doesn’t shake out in practice.
You can’t add a biome without overwriting the entire overworld, for example. You can’t create a worldgen feature and add it to every appropriate biome without listing them all individually (there’s no way to ensure your desert structure ends up in a desert-like biome from another datapack without specifically hardcoding it).
Modlaoders had to step in to fill the gaps. Fabric provides a “biome modfication” API; the mod Terrablender provides ways for different mods to share the same overworld.
Commands are a very slow programming language
On the topic of making things with Minecraft commands and mcfunction files.
Commands have a lot of inherent overhead.
- Parsing and validation.
- Reading NBT.
- Managing command arguments.
- Repeatedly rerunning the same entity selectors.
- Storing all data on the scoreboard instead of a real variable.
One line of Minecraft commands easily causes a thousand lines of Java code to run.
There is no generalized system for “event handlers”. You cannot react to an event from a datapack, you must check every single tick if the conditions for the event are now met. You can sometimes jank something together with advancements, if you happen to be watching some property of the player that Mojang decided to add an advancement for.
Therefore, datapacks involving function files often lead to nasty performance surprises down the line.
Data ossifies
If you make a system configurable through JSON data files, “special cases” become against the grain. If it’s data-driven, it’s easy to add more of the same type of thing, but adding a unique thing becomes difficult.
It’s not possible to create the leather armor dying recipe, for example, with JSON files. Even though recipes are largely data-driven these days, leather dying remains an exception.
Tags are a bad abstraction
In that vein: tags can create lists of things that are in some way “the same”. This is great if you want to add “more of the same”, and is not useful if you want to add something new.
Tags are also missing a “key-value” system (afaik Quilt experimented with one but it never caught on). For example, as of writing (1.21.9) the furnace burn times of items are hardcoded to match specific tags: by tagging your item with boats you can make it have a furnace burn time of 1200 ticks, by tagging an item with banners you can make it have a burn time of 300 ticks. If these tags are later bestowed with meaning other than “burn times”, your items will pick that up too. If you want to make an item with a different burn time than the hardcoded tag IDs permit: too bad.
Data is not code
Tags only meaningfully affect the game in ways Mojang permits them to. If you want to change the game in a way Mojang did not anticipate, too bad. Basic features, like the ability to add new blocks and items, are still missing after years (due to the code complexity involved in allowing blocks and items to appear and disappear at runtime), leading people to reskin existing blocks and hope noone notices.
I know that some people find it fun to use font resourcepack hacks + misuse chest GUIs + five mcfunctions that run every tick in order to create basic functionality that you can do correctly in five minutes with a mod. I don’t find it fun.
Data resists abstraction
You want to create recipes for sixteen colors of stained glass. What to do.
In any reasonable programming language, you loop over the colors and stamp out a recipe for each color. In datapacks, because data is not code and you don’t have loops or functions, you must create a recipe file for the red stained class, copy and paste it for the orange glass, copy and paste it for the yellow glass…
This is so ridiculous to expect of people that Mojang doesn’t even dogfood their own datapack system. They wrote internal tools that stamp out thousands of JSON files based on a code specification (“data generation”). The ideas live in code, then they’re flattened into a bunch of json files, then they’re read back by more code. The JSON files are just an intermediate format.
(It didn’t have to be like this: Factorio uses an embedded copy of Lua. If you want to create sixteen items you can just use a loop!)
A second class of content
Datapacks in general only affect the game in ways Mojang permitted them to. If they don’t add a hook for something (and you can’t come up with a horrible hacky workaround), you just can’t do it.
Only people with access to code can create certain classes of content, like complex crafting-table recipes.
People with access to code have much better tooling (compile-time validation, for example) and a much better development experience.
In conclusion
Datapacks are not my favorite method of authoring content.