How to Combine Datapacks Without Conflicts

Running a single datapack is easy. Running five or ten at the same time, which is what most servers end up doing, introduces a class of problems that Mojang's datapack system does nothing to prevent. Two packs modifying the same loot table, conflicting tick functions stepping on each other, recipe collisions that silently drop one version, and load-order quirks that change behavior depending on which pack was added first. This guide explains every common conflict type, how to diagnose them, and how to resolve them without losing functionality.

How datapack priority works

When multiple datapacks provide a file at the same path (same namespace, same relative location), the pack with the highest priority wins. Priority is determined by the order shown in /datapack list, packs listed later have higher priority and override packs listed earlier.

You can change priority with:

/datapack enable "file/my_pack.zip" first
/datapack enable "file/my_pack.zip" last
/datapack enable "file/my_pack.zip" before "file/other_pack.zip"
/datapack enable "file/my_pack.zip" after "file/other_pack.zip"

This matters most for loot tables, recipes, and world generation files, because those are "replace" files, only one version can exist per path.

Common conflict types

Loot table collisions

This is the most frequent problem. If Pack A modifies data/minecraft/loot_tables/entities/zombie.json to add head drops and Pack B modifies the same file to add rare armor drops, only one file wins. The other is completely ignored, no merge, no warning, no error. The zombie either drops heads or armor, never both.

To detect this, compare the folder structures of both packs. Any file with the same namespace and path is a collision. Tools like a simple diff or even sorting both file trees side by side in your file manager works for small packs.

Recipe conflicts

Two packs defining a recipe at data/minecraft/recipes/stick.json follow the same priority rules. But even if they use different namespaces, data/pack_a/recipes/better_stick.json and data/pack_b/recipes/also_better_stick.json, both recipes will load and appear in the recipe book. Players will see two custom stick recipes, which is confusing but not broken. The real issue is when both packs override the vanilla minecraft:stick recipe directly.

Tick function stacking

Unlike loot tables, tag files like tick.json and load.json are additive. If Pack A's tick.json lists pack_a:main_loop and Pack B's tick.json lists pack_b:main_loop, both functions run every tick. This is intentional and usually fine, but it means every pack with a tick function adds CPU overhead that stacks. Ten tick-heavy packs can measurably hurt TPS on modest hardware.

World generation overlap

If two packs both modify overworld biome distribution or dimension settings, the higher-priority pack's world generation wins entirely. The lower pack's biomes simply do not exist in the world. Never run two Overworld generation packs simultaneously, pick Terralith or your alternative, not both.

Diagnosing conflicts

Step one: run /datapack list and note the order. Step two: check your server log after /reload for any warnings about duplicate entries or failed parsing. Step three: test in-game. Kill the mob, open the chest, or craft the recipe that both packs claim to modify. If the result does not match what one pack promises, a collision is occurring.

For a systematic approach, extract both packs into temporary folders and compare their data/ trees. Any shared file path (not just filename, the full path including namespace) is a confirmed conflict.

Resolving conflicts by merging

When two packs modify the same loot table, you can manually merge them into a single file. Open both JSON files, combine their pools arrays into one file, and place the merged file in one of the packs (or in a new "merge" pack with the highest priority). Delete the conflicting file from the other pack.

Example: Pack A's zombie loot table adds a head drop pool. Pack B's adds a rare armor drop pool. Your merged file includes both pools in the pools array. The zombie now drops its normal loot, has a chance for a head, and has a chance for armor.

{
  "type": "minecraft:entity",
  "pools": [
    // ... original vanilla pool ...
    // ... Pack A's head drop pool ...
    // ... Pack B's armor drop pool ...
  ]
}

Namespace isolation

The cleanest way to avoid conflicts is to never touch the minecraft namespace. Packs that add content in their own namespace, data/my_pack/recipes/ instead of data/minecraft/recipes/, never collide with other packs. Unfortunately, overriding vanilla behavior requires the minecraft namespace, so this only works for purely additive content like new recipes, new advancements, or new functions.

When you create your own datapacks, always use your own namespace for new content. Only drop into the minecraft namespace when you need to override something vanilla.

VanillaTweaks' modular approach

VanillaTweaks solves this problem elegantly: their website lets you pick individual features and bundles them into a single datapack. Because they control all the files, there are never internal conflicts. If you select "more mob heads" and "player head drops," the generated zip contains one unified loot table per mob that includes both features. This is the gold standard for conflict-free multi-feature packs.

If you use VanillaTweaks alongside third-party packs, the third-party packs can still collide with VanillaTweaks' files. But at least the VanillaTweaks portion is internally consistent.

Testing combined packs

After merging or reordering, always test:

• Run /reload and check the console for errors.
• Verify /datapack list shows all packs enabled in the expected order.
• Kill mobs affected by loot table changes and verify drops.
• Craft every custom recipe to confirm it loads.
• Check advancements with /advancement grant @s everything then /advancement revoke @s everything to cycle through them.
• Monitor TPS with Spark for ten minutes under normal player load to catch tick function overhead.

A clean setup with five or six well-chosen packs, VanillaTweaks for quality-of-life, Terralith for terrain, a custom recipe pack, and a couple of gameplay tweaks, runs with near-zero overhead on any decent server hardware. The conflicts only become a real problem when you start stacking ten or more packs from different authors without auditing their file paths.

Need a server that handles this? Astroworld Hosting runs NVMe SSD, Pterodactyl panel, and DDoS protection. See features , plans from €6.39/mo.