Minecraft Bedrock Entity Events & Component Groups (2026)

Model calm, angry, powered, sleeping, baby, boss-phase, and random-variant states without duplicating your custom mob or burying the logic in scripts.

Data-driven state machinesThis guide was reviewed against the stable Minecraft Creator entity events and component groups documentation in July 2026. The examples keep permanent components separate from temporary states.

The short answer

Put components that should always exist in the entity's base components object. Put temporary or mutually exclusive components inside named component_groups. Then use entries in events to add one group and remove another.

This turns an entity definition into a small state machine. A calm guardian can become angry, receive faster movement and melee behavior, wait on a timer, and then return to calm. The same pattern works for life stages, elemental forms, boss phases, tamed states, weather reactions, or random spawn variants.

Base components versus component groups

  • Base components: identity and behavior that should remain active in every state, such as health, physics, collision, movement type, and navigation.
  • Component groups: named bundles that events can activate or remove, such as an attack goal, timer, scale, damage sensor, or interaction.
  • Events: transitions that add groups, remove groups, choose random outcomes, apply filters, or trigger other events.

Do not copy a permanent component into every group. If two active groups both define the same component, it becomes harder to reason about which value is in effect.

Step 1: define a calm state

This group gives the guardian a slow random stroll. It can be activated when the entity spawns or after an angry timer ends.

Calm component group
"component_groups": {
  "icedfox:calm": {
    "minecraft:behavior.random_stroll": {
      "priority": 7,
      "speed_multiplier": 0.6
    },
    "minecraft:behavior.look_at_player": {
      "priority": 8,
      "look_distance": 8.0
    }
  }
}

Step 2: define an angry state

The angry group adds a target goal, melee attack, faster movement, and a timer. When the timer finishes, it calls the event that restores the calm group.

Angry component group
"icedfox:angry": {
  "minecraft:movement": {
    "value": 0.34
  },
  "minecraft:behavior.nearest_attackable_target": {
    "priority": 2,
    "must_see": true,
    "reselect_targets": true,
    "entity_types": [
      {
        "filters": {
          "test": "is_family",
          "subject": "other",
          "value": "player"
        },
        "max_dist": 16
      }
    ]
  },
  "minecraft:behavior.melee_attack": {
    "priority": 3,
    "speed_multiplier": 1.2,
    "track_target": true
  },
  "minecraft:timer": {
    "looping": false,
    "time": 12,
    "time_down_event": {
      "event": "icedfox:become_calm",
      "target": "self"
    }
  }
}
A group name does nothing by itselfDefining icedfox:angry does not activate it. An event must add the group, or another component must trigger an event that does.

Step 3: add clean state transitions

Each transition removes the old state before adding the new one. Keeping both operations together prevents calm and angry goals from remaining active at the same time.

Entity events
"events": {
  "icedfox:become_angry": {
    "remove": {
      "component_groups": ["icedfox:calm"]
    },
    "add": {
      "component_groups": ["icedfox:angry"]
    }
  },
  "icedfox:become_calm": {
    "remove": {
      "component_groups": ["icedfox:angry"]
    },
    "add": {
      "component_groups": ["icedfox:calm"]
    }
  }
}

Trigger the transition manually while developing:

Event test commands
/event entity @e[type=icedfox:forest_guardian,c=1] icedfox:become_angry
/event entity @e[type=icedfox:forest_guardian,c=1] icedfox:become_calm

Use a narrow selector in test worlds. An unqualified selector can change every entity of that type and hide whether one specific instance transitions correctly.

Step 4: choose the spawn state

The built-in minecraft:entity_spawned event runs for ordinary spawning such as spawn eggs. Use it to add the default group:

Default spawn event
"minecraft:entity_spawned": {
  "add": {
    "component_groups": ["icedfox:calm"]
  }
}

Be careful when summoning with an explicit spawn event. A missing or inappropriate spawn event can bypass initialization and create an entity that has neither of the expected state groups.

Create random spawn variants

An event can use randomize with weighted outcomes. This example assigns common, mossy, or ancient groups on spawn.

Weighted spawn variants
"minecraft:entity_spawned": {
  "randomize": [
    {
      "weight": 7,
      "add": {
        "component_groups": ["icedfox:calm", "icedfox:variant_common"]
      }
    },
    {
      "weight": 2,
      "add": {
        "component_groups": ["icedfox:calm", "icedfox:variant_mossy"]
      }
    },
    {
      "weight": 1,
      "add": {
        "component_groups": ["icedfox:calm", "icedfox:variant_ancient"]
      }
    }
  ]
}

Weights 7, 2, and 1 produce a 70%, 20%, and 10% split. Give variants a measurable property or visual marker during testing so you can count the outcomes.

Gate events with filters

Filters prevent a transition unless the subject matches a condition. A root event filter can require a tag before allowing the angry group:

Filtered event
"icedfox:become_angry_if_marked": {
  "filters": {
    "test": "has_tag",
    "subject": "self",
    "value": "icedfox_can_enrage"
  },
  "remove": {
    "component_groups": ["icedfox:calm"]
  },
  "add": {
    "component_groups": ["icedfox:angry"]
  }
}

Filters can combine tests with all_of, any_of, and none_of. Keep the first test simple and observable before building a large condition tree.

Understand sequence timing

Events can use sequence to evaluate several actions in order, but component group changes are applied on the server tick. A later filter in the same event does not immediately see a component added by an earlier sequence entry.

If one transition depends on the result of another, split them across events, timers, or later ticks instead of treating the sequence like synchronous application code.

Recommended entity layout

High-level entity structure
{
  "format_version": "1.21.90",
  "minecraft:entity": {
    "description": {
      "identifier": "icedfox:forest_guardian",
      "is_spawnable": true,
      "is_summonable": true
    },
    "component_groups": {
      "icedfox:calm": {},
      "icedfox:angry": {},
      "icedfox:variant_common": {},
      "icedfox:variant_mossy": {},
      "icedfox:variant_ancient": {}
    },
    "components": {
      "minecraft:health": { "value": 40, "max": 40 },
      "minecraft:physics": {},
      "minecraft:movement.basic": {},
      "minecraft:navigation.walk": {}
    },
    "events": {
      "minecraft:entity_spawned": {},
      "icedfox:become_angry": {},
      "icedfox:become_calm": {}
    }
  }
}

The empty objects above are placeholders for the complete groups and events from the previous sections. This outline shows the ownership boundary: permanent components stay in components, state-specific components live in groups, and transitions live in events.

Entity state test checklist

  1. Spawn one entity and confirm its default group is active.
  2. Trigger each custom event with /event entity.
  3. Give every state one visible or measurable difference.
  4. Confirm the old group is removed during each transition.
  5. Wait for timers and verify they fire once or loop as intended.
  6. Spawn at least fifty entities when judging random weights.
  7. Save and reload the world while entities are in each state.
  8. Test transitions on a dedicated server or multiplayer world.

Why an entity event does not work

The /event command says the event is unknown

Check the event key, entity selector, active Behavior Pack, and entity JSON parsing. The command must target the custom entity instance that owns the event.

The event runs but behavior does not change

Give the group a simple test component such as movement speed or scale. Check whether a base component or another active group also defines the same component.

Calm and angry behavior run together

Remove the previous state group in the same transition that adds the next. Also confirm the behavior goals were not copied into base components.

The timer never resets the entity

Verify the timer is inside the active group, the time_down_event key names a real event, and its target is self.

Random variants have the wrong frequency

Check relative weights and count a meaningful sample. Ten spawns can look unbalanced even when the configuration is correct.

Frequently asked questions

Can an entity have several component groups active?

Yes. Separate concerns such as life stage, visual variant, and combat state can coexist. Avoid having active groups fight over the same component unless that override is deliberate and tested.

Do I need Script API for mob states?

No. Many state transitions, sensors, timers, filters, and AI changes are cleaner as data-driven entity events. Add scripts when the mechanic genuinely needs logic beyond the available components and filters.

Can animations trigger behavior events?

Behavior Pack animation timelines can trigger entity events. Keep visual animation controllers and server behavior responsibilities clear, then test timing under multiplayer latency.

Official sources checked