Pack Load Order and File Conflict Resolution

In the World Edit screen and inside the world configuration files (`world_behavior_packs.json` and `world_resource_packs.json`), active packs are arranged in a vertical list. The top of this list has the highest priority, and the bottom of the list—right above the built-in vanilla packs—has the lowest priority.

Internally, the game loads packs from the bottom up. It starts with the base vanilla assets and data, then applies the lowest custom pack in the list, and works its way up to the pack at index 0. Because the top pack is processed last, its definitions have the final say whenever two packs attempt to modify the same identifier or file path.

Server owners and mapmakers control this order directly through the world's JSON pack lists. The `world_behavior_packs.json` file sits inside the world folder and is read as an array where the first object is the highest priority pack.

[
  {
    "pack_id": "01234567-89ab-cdef-0123-456789abcdef",
    "version": [ 1, 0, 0 ]
  },
  {
    "pack_id": "fedcba98-7654-3210-fedc-ba9876543210",
    "version": [ 2, 1, 0 ]
  }
]

A common misconception is that Bedrock only cares about folder structures and file names when deciding what to overwrite. For most data-driven definitions—including entities, blocks, items, recipes, and render controllers—the game resolves conflicts by the internal `identifier` string rather than the file path.

For example, if Pack B (low priority) defines `minecraft:zombie` inside `BP/entities/custom_zombie.json`, and Pack A (high priority) defines `minecraft:zombie` inside `BP/entities/undead/zombie_override.json`, Pack A still wins. Even though the file paths are completely different, the engine sees that both files register the `minecraft:zombie` identifier and discards the lower-priority definition.

Pure assets without an internal JSON identifier—such as `.png` textures, `.ogg` or `.fsb` audio files, and `.mcfunction` files—are resolved strictly by their relative file path. If two resource packs provide `RP/textures/blocks/stone.png`, the pack higher in the stack supplies the texture.

Not every file in a Bedrock add-on is winner-take-all. Because certain files act as global registries for the entire pack, the engine merges their contents across the pack stack so that multiple add-ons can add custom blocks, sounds, and textures at the same time. Only duplicate keys inside those merged files will overwrite one another.

Conversely, individual definition files (like a specific entity or loot table) are never merged key-by-key across packs. If two packs modify the same vanilla entity, the higher-priority pack completely replaces the lower-priority pack's file; their component lists are not combined.

Because `terrain_texture.json` and `item_texture.json` merge their `texture_data` objects across every active resource pack, your choice of texture shortname determines whether your pack will conflict with others. If two packs both register a generic shortname like `ruby` or `steel_ingot` inside `item_texture.json`, the higher-priority pack will overwrite that key, causing the lower-priority pack's item to render with the wrong icon.

To guarantee your entries merge cleanly without key collisions, prefix your texture shortnames, sound event keys, and geometry identifiers with your creator namespace, just as you do for block and item identifiers.

{
  "resource_pack_name": "my_custom_pack",
  "texture_name": "atlas.items",
  "texture_data": {
    "myname_mythril_ingot": {
      "textures": "textures/items/mythril_ingot"
    },
    "myname_mythril_sword": {
      "textures": "textures/items/mythril_sword"
    }
  }
}

The single most common point of failure when combining two Behavior Packs is `BP/entities/player.json`. Because the player entity (`minecraft:player`) is governed by the Full Overwrite rule, only one pack in the stack can modify `player.json`. If Pack A adds a custom component group to the player for a thirst bar, and Pack B modifies the player to change maximum health, whichever pack sits higher in the load order completely erases the other pack's player changes.

The same problem applies to the client entity file (`RP/entity/player.entity.json`) when multiple resource packs attempt to attach custom animations or render controllers to the player model.

If you are building an add-on intended to be used alongside other packs, avoid editing `BP/entities/player.json` unless there is no alternative. For gameplay mechanics, use the Script API (`@minecraft/server`) to listen to events, manage dynamic properties, or apply effects to players at runtime. Every pack gets its own isolated script execution environment, so scripts from multiple packs run side by side without overwriting each other.

Applies to all modern Minecraft Bedrock versions (1.16.0 through 1.21+). No experimental toggles are required for standard pack stacking and merging behavior.

Read out of the game itself, so the ids match the version you are building for.