Entity Identifier Conflicts Between Two Add-Ons

In Minecraft Bedrock, an entity is linked to its behaviour and visuals purely through the identifier string inside its description block, not by the name of the JSON file on your disk. When the game loads a world, it reads the active behaviour packs and resource packs from the bottom of the load order up to the top. If two packs contain an entity definition with the exact same identifier, the pack higher in the list completely replaces the definition from the lower pack.

Crucially, Bedrock does not merge entity JSON files. You cannot write a small file containing only a health component and expect the game to patch it into the existing entity. If you include an entity file for a vanilla cow or the player in your behaviour pack, you must include every single component, component group, and event that the entity needs to function. Anything you leave out is stripped from the entity in-game, and any changes made by a pack lower in the load order are discarded entirely.

{
  "format_version": "1.20.0",
  "minecraft:entity": {
    "description": {
      "identifier": "minecraft:player",
      "is_spawnable": false,
      "is_summonable": false
    },
    "components": {
      "minecraft:health": {
        "value": 40,
        "max": 40
      }
    }
  }
}

The most common victim of add-on conflicts is the player entity, identified as minecraft:player. Many creators edit BP/entities/player.json to attach custom environment sensors, alter base movement speed, or trigger functions via animation controllers. Because there is only one player identifier, two add-ons that both ship a modified player.json can never work together out of the box.

The same problem affects popular vanilla mobs like villagers, zombies, and iron golems. If Pack A edits the zombie to drop custom loot and Pack B edits the zombie to break down doors faster, putting Pack B at the top of the behaviour pack list erases Pack A's loot table change. Even if you rename your file to BP/entities/my_custom_zombie.json, the engine still sees the minecraft:zombie identifier inside the file and overwrites the entire definition.

An even stranger failure occurs when a user stacks two conflicting add-ons in different orders across the Behaviour Pack and Resource Pack screens. Suppose Pack A is on top of the Behaviour Pack list, but Pack B is on top of the Resource Pack list, and both modify the vanilla pig.

In this scenario, the pig runs the server-side logic from Pack A, but the client renders it using the client_entity definition from Pack B. If Pack A triggers custom entity events that set properties or actor flags, Pack B's client entity will not know how to display them. Conversely, if Pack B's resource definition runs Molang queries looking for a specific mark_variant or skin_id that only Pack A's behaviour file knows how to set, the pig will render with broken animations, missing textures, or invisible geometry.

Vanilla entities are not the only source of trouble. Creators who use generic namespaces like custom:, addon:, or mob: frequently collide with other authors who picked the same generic prefix. If two different furniture packs both define an invisible chair entity named custom:seat, the game treats them as the exact same entity.

To prevent this, always construct your namespace from your studio name and a short code for the specific project. While you cannot stop another pack from overwriting minecraft:player if you choose to edit it, you have complete control over keeping your own custom entities isolated from the rest of the community.

{
  "format_version": "1.20.0",
  "minecraft:entity": {
    "description": {
      "identifier": "acme_dungeon:forest_goblin",
      "is_spawnable": true,
      "is_summonable": true
    },
    "components": {
      "minecraft:type_family": {
        "family": [ "goblin", "monster", "mob" ]
      },
      "minecraft:health": {
        "value": 20,
        "max": 20
      },
      "minecraft:movement": {
        "value": 0.25
      }
    }
  }
}

Since modern Bedrock versions support the @minecraft/server Script API, you rarely need to include vanilla entity JSON files in your behaviour pack anymore. Instead of overriding player.json to run a sensor or alter health, you can listen to world events in JavaScript and apply effects, run commands, or manipulate entity state dynamically.

Because scripts run alongside each other in isolated contexts rather than overwriting a shared definition file, multiple script-based add-ons can interact with the player and vanilla mobs at the same time. If you only need to add a variant of a vanilla mob—such as a new type of zombie—create a brand-new entity with your own namespace and a spawn rule, rather than editing the vanilla zombie file.

import { world } from "@minecraft/server";

world.afterEvents.EntitySpawn.subscribe((event) => {
  const entity = event.entity;
  if (entity.typeId === "minecraft:zombie") {
    entity.addEffect("speed", 2000, { amplifier: 1, showParticles: false });
  }
});

Applies to all Bedrock Edition versions. The Script API alternative uses stable @minecraft/server features and does not require experimental toggles in 1.20+ when using matching module versions.

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