Running Entity Commands from Animation Controllers

Minecraft Bedrock uses the same state machine syntax for animation controllers in both resource packs and behavior packs, which frequently trips up new creators. Resource pack controllers live in RP/animation_controllers/ and only handle client-side visuals, sounds, and particle effects. They cannot modify world state or run slash commands.

To run commands on an entity, the controller file must sit inside BP/animation_controllers/. Because behavior packs run on the server (or the local host's internal server), states inside these files have full authority to execute slash commands, dispatch entity events, and write to server-side Molang variables. The format_version for behavior pack animation controllers is 1.10.0, even inside packs targeting the latest game releases.

Inside a behavior pack animation controller state, the arrays on_entry and on_exit accept strings. The engine determines what to do with each string by looking at its first character. A forward slash runs a standard game command, an at-symbol fires an event on the entity, and anything else is parsed as raw Molang.

Commands execute with the entity itself as both the executor and the execution position. This means the selector @s always targets the entity running the controller, and relative coordinates like ~ ~1 ~ resolve relative to the entity's feet. Commands executed this way bypass normal player permission levels and do not spam the chat log unless command block output is explicitly enabled in the world settings.

A controller contains one or more states, always starting at the state named default unless you specify a different initial_state. Each state can define on_entry, on_exit, and transitions. When the Molang condition inside a transition evaluates to true (non-zero), the controller leaves the current state, runs any strings in on_exit, moves to the target state, and immediately runs the strings in the new state's on_entry array.

The example below watches the entity's target state using query.has_target. The moment the entity acquires a target, it transitions from default to roaring. Entering roaring plays a roar sound, gives the entity a speed boost, Summons particles via a command, and triggers an entity event to add an angry component group. When the target is lost or dies, it transitions back to default, clearing the speed effect on the way out.

{
  "format_version": "1.10.0",
  "animation_controllers": {
    "controller.animation.wiki.roar_attack": {
      "initial_state": "default",
      "states": {
        "default": {
          "transitions": [
            {
              "roaring": "query.has_target"
            }
          ]
        },
        "roaring": {
          "on_entry": [
            "/playsound mob.ravager.roar @a ~ ~ ~ 1.0 1.0",
            "/effect @s speed 10 1 true",
            "/particle minecraft:villager_angry ~ ~2 ~",
            "@s wiki:start_enrage"
          ],
          "on_exit": [
            "/effect @s speed 0"
          ],
          "transitions": [
            {
              "default": "!query.has_target"
            }
          ]
        }
      }
    }
  }
}

An animation controller file does nothing on its own; it must be registered and ticked inside your entity's behavior file under description. First, assign a short name to the controller identifier inside the animations object. Despite the key being named animations, it holds both timeline animations and animation controllers.

Next, add that short name to the scripts.animate array. Every entry in scripts.animate is evaluated every tick the entity is loaded. You can either pass the short name as a plain string so it always runs, or pass an object mapping the short name to a Molang condition so the controller only ticks when that condition is true.

{
  "format_version": "1.20.0",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:custom_guard",
      "is_spawnable": true,
      "is_summonable": true,
      "animations": {
        "roar_ctrl": "controller.animation.wiki.roar_attack"
      },
      "scripts": {
        "animate": [
          "roar_ctrl"
        ]
      }
    },
    "component_groups": {
      "wiki:enraged": {
        "minecraft:scale": {
          "value": 1.25
        }
      }
    },
    "components": {
      "minecraft:health": {
        "value": 40,
        "max": 40
      },
      "minecraft:NearestAttackableTargetGoal": {
        "must_see": true,
        "entity_types": [
          {
            "filters": {
              "test": "is_family",
              "subject": "other",
              "value": "monster"
            }
          }
        ]
      }
    },
    "events": {
      "wiki:start_enrage": {
        "add": {
          "component_groups": [
            "wiki:enraged"
          ]
        }
      }
    }
  }
}

Strings inside on_entry and on_exit only fire once per state change. If you need a command to fire repeatedly while a condition holds—such as running a /damage or /particle command every single tick—you use a two-state loop. Create a second state that has no conditions on its transition back to the first state, or bounces between two active states using the unconditional Molang value (1.0).

Because the controller processes one transition per tick, bouncing between state_a and state_b with "1.0" as the transition condition causes the controller to enter one of those states every other tick (10 times a second). If you put the same on_entry commands in both states, those commands will execute on all 20 ticks per second for as long as the entity stays in the loop. For longer intervals without using commands every tick, pair the controller with a behavior pack timeline animation instead.

{
  "format_version": "1.10.0",
  "animation_controllers": {
    "controller.animation.wiki.flame_trail": {
      "initial_state": "idle",
      "states": {
        "idle": {
          "transitions": [
            {
              "tick_a": "query.is_moving"
            }
          ]
        },
        "tick_a": {
          "on_entry": [
            "/particle minecraft:basic_flame_particle ~ ~0.2 ~"
          ],
          "transitions": [
            {
              "idle": "!query.is_moving"
            },
            {
              "tick_b": "1.0"
            }
          ]
        },
        "tick_b": {
          "on_entry": [
            "/particle minecraft:basic_flame_particle ~ ~0.2 ~"
          ],
          "transitions": [
            {
              "idle": "!query.is_moving"
            },
            {
              "tick_a": "1.0"
            }
          ]
        }
      }
    }
  }
}

When an entity needs to run more than three or four commands on a state change, listing them all inside on_entry makes the JSON harder to read and maintain. Instead, place your commands inside a standard .mcfunction file in BP/functions/ and call it from the controller using "/function your_file_name".

The function inherits the execution context of the animation controller, meaning @s inside the .mcfunction file still points to the entity that triggered the transition, and ~ ~ ~ still uses that entity's coordinates.

Stable in all current Bedrock versions (introduced in 1.10.0). No experimental toggles are required. The animation controller file itself must keep format_version 1.10.0, while the entity file can use 1.16.0 through 1.21.x.

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