Playanimation Command Recipes and Animation Controller Setup

At its simplest, /playanimation only needs a target selector and the full identifier of an animation that already exists in a loaded resource pack. Every parameter after the animation name is optional, though because the syntax is positional, you have to fill in the earlier optional slots if you want to reach one near the end. The command runs purely on the client side once the server dispatches the packet, which means the server does not validate whether the bones referenced in the animation actually exist on the target's geometry.

Understanding how the last three parameters interact is the difference between an animation that snaps uglily and one that blends smoothly into vanilla movement. The stop expression is evaluated as Molang on the client every frame while the animation is active; the moment it returns a non-zero value (true), the animation begins blending out over the duration specified by blend_out_time. The controller parameter names a runtime slot on the entity: playing a new animation on the same named controller replaces whatever was running in that slot previously, while leaving it blank or using distinct names lets multiple animations layer on top of one another.

A major advantage of /playanimation is that you do not have to edit RP/entity/<mob>.entity.json to register a shortname for the animation before calling it. As long as an animation file inside RP/animations/ defines the full identifier—such as animation.humanoid.celebrate—the command can look it up globally by that string. When the client receives the command, it matches the bone names inside the animation against the bone names in the target entity's current geometry.

Because most vanilla bipedal mobs (players, zombies, skeletons, piglins, villagers to a partial extent) share standardized bone names like head, body, rightArm, leftArm, rightLeg, and leftLeg, a single custom animation file in your resource pack can be played on almost any humanoid mob through /playanimation. Bones mentioned in the animation that do not exist on the target's geometry are silently ignored, and bones on the target that are not mentioned in the animation keep running their normal vanilla walk or idle controllers.

{
  "format_version": "1.8.0",
  "animations": {
    "animation.custom.salute": {
      "loop": false,
      "animation_length": 1.5,
      "bones": {
        "rightArm": {
          "rotation": {
            "0.0": [0.0, 0.0, 0.0],
            "0.25": [-135.0, -25.0, 10.0],
            "1.25": [-135.0, -25.0, 10.0],
            "1.5": [0.0, 0.0, 0.0]
          }
        },
        "head": {
          "rotation": {
            "0.0": [0.0, 0.0, 0.0],
            "0.2": [-5.0, 0.0, 0.0],
            "1.3": [-5.0, 0.0, 0.0],
            "1.5": [0.0, 0.0, 0.0]
          }
        }
      }
    },
    "animation.custom.cower_loop": {
      "loop": true,
      "bones": {
        "head": {
          "rotation": [35.0, 0.0, 0.0]
        },
        "rightArm": {
          "rotation": [-110.0, -35.0, 0.0]
        },
        "leftArm": {
          "rotation": [-110.0, 35.0, 0.0]
        }
      }
    }
  }
}

When you put these commands inside a behavior pack .mcfunction file, you generally fall into one of three patterns: playing a one-shot gesture that finishes on its own, starting an indefinite pose that waits for a gameplay condition to change, or cancelling an active loop on demand. For a one-shot animation where loop is false in the JSON (or where it is a vanilla non-looping animation), you only need the first two arguments, or up to the fourth if you want a smooth blend out at the end.

For looping animations—including many vanilla pose animations that have no fixed length—the animation will stay stuck on the entity forever unless you give it a way out. You can either pass a Molang query in the stop_expression slot so the client automatically releases the pose when the entity moves, takes damage, or sneaks, or you can assign a custom controller track name in the sixth slot. To cancel a named track later from a command or function, call /playanimation again on the same entity and the same controller name, pass a valid animation identifier, and set the stop_expression to "1" so it terminates immediately.

# 1. Simple one-shot using our custom RP animation, blending out over 0.3 seconds
playanimation @e[type=minecraft:zombie,c=1] animation.custom.salute default 0.3

# 2. Hold a cowering loop until the entity starts moving or takes damage
playanimation @e[type=minecraft:villager,r=10] animation.custom.cower_loop default 0.4 "query.modified_move_speed > 0.1 || query.hurt_time > 0" custom_pose_track

# 3. Lock an armor stand or mob into a sleeping/lying pose indefinitely (stop_expression = 0)
playanimation @e[type=minecraft:armor_stand,tag=statue] animation.player.sleeping default 0.0 "0" statue_track

# 4. Force-cancel whatever is currently running on 'custom_pose_track' with a 0.25s blend out
playanimation @e[type=minecraft:villager,r=10] animation.custom.cower_loop default 0.25 "1" custom_pose_track

Even in a behavior-pack-only project with no custom resource pack attached, /playanimation can tap into hundreds of animations shipped in the vanilla resource pack. Because the command matches bones by name rather than checking entity types, you can borrow animations from one mob and run them on another so long as they share bone names like body, head, or root.

This technique is widely used for visual tricks: scaling an entity up or down with the creeper swelling or ghast scale animations, spinning mobs upside down or sideways using swimming and sleeping animations, or applying a first-person camera shake to players by targeting their root or camera bones. Keep in mind that some vanilla animations rely on entity-specific Molang variables initialized in that mob's client entity file; if an animation looks frozen or snaps to weird angles on a foreign mob, it usually means a variable like variable.attack_time or a mob-specific timer is missing on the target.

If your add-on uses @minecraft/server scripts rather than .mcfunction files, you do not need to build command strings and pass them to runCommand. The Entity class exposes a native playAnimation(animationName, options) method that sends the exact same network packet with cleaner syntax and type-safe options.

All four optional parameters from the slash command map directly onto the PlayAnimationOptions object: nextState, blendOutTime, stopExpression, and controller. In addition, the Script API adds a players property—an array of Player objects—allowing you to play an animation on an entity so that only specific players in the world see it, which is impossible with the slash command alone.

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

/**
 * Plays a looping cower animation on nearby villagers that stops if they move,
 * and cancels it manually after 5 seconds (100 ticks).
 */
export function frightenNearbyVillagers(originPlayer) {
  const villagers = originPlayer.dimension.getEntities({
    type: "minecraft:villager_v2",
    location: originPlayer.location,
    maxDistance: 12
  });

  for (const villager of villagers) {
    villager.playAnimation("animation.custom.cower_loop", {
      blendOutTime: 0.35,
      stopExpression: "query.modified_move_speed > 0.15",
      controller: "fear_track"
    });
  }

  system.runTimeout(() => {
    for (const villager of villagers) {
      if (!villager.isValid()) continue;
      villager.playAnimation("animation.custom.cower_loop", {
        blendOutTime: 0.5,
        stopExpression: "1",
        controller: "fear_track"
      });
    }
  }, 100);
}

The /playanimation command has been available in stable Bedrock releases since 1.16.100 and requires no experimental toggles. In @minecraft/server, Entity.playAnimation is stable in 1.3.0 and later module versions.

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