Entity events in Minecraft Bedrock

Entity events

Use entity events in Bedrock add-ons to add and remove component groups, pick random outcomes, run steps in order, chain events and set properties.

Events are how a mob changes. A baby grows up, a tame wolf sits, a creeper starts to fuse: each of those is an event switching component groups on or off. This page shows everything an event can do, using the Ruby Golem from The entity file.

The files

Events live in the same file as the rest of the mob's behavior, in the events block.

Behavior pack

BP/
  entities/
    ruby_golem.json    <- "events" is inside minecraft:entity

What an event looks like

An event is a name with an object of actions. When the event fires, the game runs the actions.

BP/entities/ruby_golem.json (events)

"events": {
  "wiki:become_angry": {
    "add": { "component_groups": ["wiki:angry"] },
    "remove": { "component_groups": ["wiki:calm"] }
  }
}

Give your events your own namespace, like wiki:become_angry. The minecraft: names are for events the game itself fires.

Every action at a glance

Action	What it does
`add`	Switches on one or more component groups
`remove`	Switches off one or more component groups
`set_property`	Changes a property declared in `description.properties`
`trigger`	Fires another event
`randomize`	Picks one entry from a list, by weight
`sequence`	Runs every entry in a list, from top to bottom
`first_valid`	Runs the first entry whose filters pass, and skips the rest
`filters`	Only lets the actions run if a filter passes
`queue_command`	Runs a command as the mob, on the next tick
`play_sound`	Plays one of the mob's sounds, like `"saddle"` on a camel

add and remove

These two do most of the work. Both take a list, so you can switch several groups at once.

Inside an event

"add": { "component_groups": ["wiki:angry", "wiki:glowing_eyes"] },
"remove": { "component_groups": ["wiki:calm"] }

The groups must exist in component_groups in the same file. If a name is spelled wrong, that group is simply not added, so check names carefully.
Adding a group that is already on restarts it. A timer inside it starts counting from zero again.
Removing a group that is not on does nothing, so it is safe to remove "just in case".

set_property

Changes a property on the mob. The property must be declared in the description.

Inside an event

"set_property": {
  "wiki:mood": "angry",
  "wiki:rubies_eaten": "math.min(q.property('wiki:rubies_eaten') + 1, 5)"
}

The value can be a plain value, or a Molang expression in a string. The second line above adds 1 each time, but never goes past 5. See Molang queries for what you can read.

trigger: chain events

trigger fires another event. This lets you write a piece of logic once and reuse it.

Inside an event

"trigger": "wiki:calm_down"

You can also say who receives the event:

Inside an event

"trigger": {
  "event": "wiki:calm_down",
  "target": "self"
}

randomize: pick one

randomize holds a list of entries. The game picks one of them and runs it. Each entry can have a weight: bigger weights are picked more often. An entry without a weight counts as 1.

BP/entities/ruby_golem.json (events)

"minecraft:entity_spawned": {
  "randomize": [
    {
      "weight": 3,
      "trigger": "wiki:spawn_adult"
    },
    {
      "weight": 1,
      "trigger": "wiki:spawn_baby"
    }
  ]
}

The chance of each entry is its weight divided by the total. Here the total is 4, so an adult has a 3 in 4 chance (75%) and a baby has 1 in 4 (25%).

An entry can also be just { "weight": 3 } with no actions. That means "3 parts chance of doing nothing".

sequence: do several things in order

sequence runs every entry, from first to last. It becomes powerful when entries have their own filters: each one only runs if its check passes.

BP/entities/ruby_golem.json (events)

"wiki:fed_ruby": {
  "sequence": [
    {
      "set_property": {
        "wiki:rubies_eaten": "q.property('wiki:rubies_eaten') + 1"
      }
    },
    {
      "filters": { "test": "is_baby", "value": true },
      "trigger": "wiki:grow_up"
    },
    {
      "filters": { "test": "int_property", "domain": "wiki:rubies_eaten", "operator": ">=", "value": 4 },
      "add": { "component_groups": ["wiki:shiny"] }
    }
  ]
}

Changes land at the end

When an event runs, the game works out all of its actions first and applies them when the mob next updates. So a filter in a later entry of a sequence still sees the old values. In the example above, the third entry checks the count from before the first entry added 1. Keep that in mind, or split the logic into two events.

first_valid: the first match wins

first_valid looks like sequence, but it stops after the first entry whose filters pass. It is perfect for "if this, else if that, else...". Vanilla cows use it to pick a warm or cold look from the biome they spawn in.

BP/entities/ruby_golem.json (events)

"wiki:pick_color": {
  "first_valid": [
    {
      "filters": { "test": "has_biome_tag", "value": "desert" },
      "add": { "component_groups": ["wiki:sandy"] }
    },
    {
      "filters": { "test": "has_biome_tag", "value": "frozen" },
      "add": { "component_groups": ["wiki:icy"] }
    },
    {
      "add": { "component_groups": ["wiki:plain"] }
    }
  ]
}

The last entry has no filters, so it always passes. It acts as the "otherwise" case.

filters on the whole event

You can put filters straight on an event. If the filter fails, nothing in the event runs.

BP/entities/ruby_golem.json (events)

"wiki:become_angry": {
  "filters": { "test": "is_baby", "value": false },
  "add": { "component_groups": ["wiki:angry"] }
}

Now baby golems never get angry. This needs a format_version of 1.19.20 or newer. With an older version the game skips the filter and always runs the event.

queue_command

Runs a command as if the mob typed it. It runs within the next tick, unless the mob is gone by then.

Inside an event

"queue_command": {
  "command": "say I am made of rubies!"
}

Handy for small things like particles, sounds or tags ("tag @s add wiki:tamed"). For anything bigger, a function or a script is easier to manage.

Events the game fires for you

Some events have fixed minecraft: names. If your mob has an event with one of these names, the game fires it at the right moment.

Event	When it fires
`minecraft:entity_spawned`	When the mob first appears: natural spawning, a spawn egg or `/summon`
`minecraft:entity_born`	When the mob is born from two parents breeding
`minecraft:entity_transformed`	When another mob turns into this one, through `minecraft:transformation`

minecraft:entity_spawned is where most mobs set up their starting state, like choosing between adult and baby.

Other ways to fire an event

Components. Many components take an event, such as timer, damage_sensor, environment_sensor, interact and ageable.
Commands. /event entity @e[type=wiki:ruby_golem] wiki:become_angry fires it on every Ruby Golem.
Summoning. /summon wiki:ruby_golem ~ ~ ~ 0 0 wiki:spawn_baby spawns the golem and fires an event right away. See /summon.
Spawn rules. The herd condition can fire an event on part of a group. See Spawn rules.

When something goes wrong

What you see	Most likely cause
Nothing happens	The event name is spelled differently where it is fired, or nothing fires it at all
The group is not added	The group name in `add` is not in `component_groups`
A `sequence` filter seems wrong	It sees the values from before the event started: see the warning above
A root filter is ignored	The file's `format_version` is older than `1.19.20`
`randomize` always picks the same	One weight is much bigger than the others

Test events quickly by firing them with /event on a single mob. More help is in Troubleshooting. Next: Spawn rules.