FMBE: Fox Modded Block Entities for Vanilla Display Props

When you need to render an arbitrary block at an off-grid angle or a non-standard scale without shipping a custom resource pack geometry, you have to hijack an existing vanilla entity's item renderer. Armor stands can hold blocks and can be posed, and players have historically used them for 3D props. However, armor stands have a noisy bone hierarchy, cannot easily be made completely invisible without hiding their held items on certain render Dragon pipelines unless specific animations are layered, and require several chained animations to zero out their base poses.

The vanilla fox (`minecraft:fox`) solves most of these problems. A fox renders whatever is placed in its `slot.weapon.mainhand` inside its mouth. In the vanilla client resource pack, that mouth locator sits inside the `head` bone, which is a child of the `body` bone. Because the fox has a relatively clean skeletal hierarchy and responds predictably to vanilla animation overrides, you can apply the `minecraft:invisibility` status effect to hide the fox mesh itself while the item in its mouth remains completely visible.

The core of the FMBE recipe is the `/playanimation` command. Although `/playanimation` can only trigger animation names that are already registered in the client's loaded resource packs, several vanilla animations use Molang variables (`variable.*`) rather than hardcoded keyframes for their bone transforms. Because all animations running on a single entity share the same `variable.` scope, you can play one animation whose sole job is to initialize or overwrite a Molang variable, and simultaneously play a second animation that reads that variable and applies it to the `body` or `head` bone's position, rotation, or scale.

Before you apply any bone transformations, you have to spawn a fox and strip away its normal AI and physics so it behaves like a static prop. In a pure command block setup or a behavior pack function, you start by summoning the entity, tagging it so your transformation commands only target this specific instance, and replacing its mainhand slot with the block or item you want to display.

A raw summoned fox will walk around, look at nearby players, sleep, and drop its held item if it sees food on the ground. In a command-only workflow, you freeze it in place by repeating a `/tp` command on a tick loop or by giving it extreme slowness, and you clear its head look behavior using animations. If you are building a Behavior Pack, a cleaner method is to add a custom component group to `BP/entities/fox.json` that removes movement, gravity, pushability, and look goals altogether, leaving a lightweight dummy entity.

You also need to keep the fox invisible. Applying `/effect @e[tag=fmbe_init] invisibility 99999 1 true` hides the fox skin and particles while leaving the held block intact. Finally, if the fox takes damage from AoE attacks or falling anvils, it will flash red and make noise. In vanilla commands, `/effect @e[tag=fmbe_init] resistance 99999 255 true` prevents most damage; in a Behavior Pack, `minecraft:damage_sensor` set to deal no damage is preferred.

# Summon at execution location and tag immediately
summon minecraft:fox ~ ~ ~ ~ ~ minecraft:entity_spawned
tag @e[type=minecraft:fox,c=1,r=2,tag=!fmbe] add fmbe_init

# Put the display block in the fox's mouth
replaceitem entity @e[tag=fmbe_init] slot.weapon.mainhand 0 minecraft:sea_lantern 1

# Hide the fox body and protect it from casual damage
effect @e[tag=fmbe_init] invisibility 999999 1 true
effect @e[tag=fmbe_init] resistance 999999 255 true
effect @e[tag=fmbe_init] slowness 999999 255 true

# Promote to active tag
tag @e[tag=fmbe_init] add fmbe
tag @e[tag=fmbe_init] remove fmbe_init

If you leave an invisible fox sitting in the world with a block in its mouth, the block will be tilted on its side, slightly shrunken, and bobbing up and down as the fox breathes and looks around. This happens because the default fox controller runs `animation.fox.move`, `animation.fox.look_at_target`, and `animation.fox.setup`, which apply a default tilt to the head and place the held item at the angle of a fox carrying prey.

To turn the fox into a clean origin point, you have to zero out the vanilla animations and neutralize the base bone offsets. You do this by sending `/playanimation` commands with a very high blend weight or by overriding the active controller states. Specifically, you need an animation that locks the `head` and `body` bones so the AI look goals cannot rotate them, and you need to undo the base 90-degree rotation of the fox body and the tilt of the held item.

Creators do this by firing a stack of static vanilla animations once upon spawning. While the exact combination depends on whether you want the block centered on the entity's hitbox or aligned to the block grid, the underlying mechanism is always the same: you specify a huge `stop_expression` time or a Molang condition like `query.is_alive` (or simply `0` so the stop expression never evaluates to true) and a blend out time of `0` so the pose holds indefinitely while the chunk is loaded.

The syntax for `/playanimation` is `/playanimation <entity> <animation> [next_state] [blend_out_time] [stop_expression] [controller]`. The secret to dynamic FMBE control lies in the `[stop_expression]` and `[blend_out_time]` parameters. The `[stop_expression]` field is a full Molang string that the client evaluates every frame to decide whether the animation should terminate. Because it is a full Molang string, you are allowed to write assignment statements inside it—such as `v.x = 10; return 0;`—and those assignments modify the entity's live Molang variables on the client.

Once you realize you can write arbitrary Molang into `[stop_expression]`, the limitation shifts from 'how do I set a variable' to 'which vanilla animations actually read `v.*` variables and apply them to `head` or `body` transforms'. The vanilla resource pack includes dozens of animations across mobs (wither, armor stand, agent, tripod camera, tropical fish, phantom, and player) that reference generic variable names or runtime expressions in their position, rotation, or scale channels.

For example, if a vanilla animation scales the `head` or `body` bone using a Molang variable or a smooth blend curve, you play that animation on a named custom controller slot on the fox. Then, on a second custom controller slot, you play any dummy animation (such as `animation.fox.baby_transform` or `animation.player.sleeping`) and place your Molang variable assignments inside its `stop_expression`. Because the stop expression returns `0` at the end of the string, the dummy animation never stops, and your custom variable assignments are re-evaluated or preserved for the bone-driving animation to read.

# Example pattern for injecting Molang variables via stop_expression
# Note: The stop_expression string must evaluate to 0 (false) so the animation keeps running.

# 1. Inject custom variables into the entity's Molang scope using a dummy controller
playanimation @e[tag=fmbe] animation.Creeper.swelling none 0 "v.fmbe_scale = 1.5; v.fmbe_rot_y = 45; return 0;" fmbe_var_injector

# 2. Apply vanilla animations to lock head movement so AI look goals do not jitter the prop
playanimation @e[tag=fmbe] animation.armor_stand.no_pose none 0 "0" fmbe_lock_pose

The single biggest architectural catch with `/playanimation` (and therefore with FMBE) is that it is a transient client-side packet. The server does not save active `/playanimation` states to the entity's NBT data on disk. When a player walks far enough away for the chunk to unload on their client, or when a player logs out and back into the world, the fox entity reloads in its default vanilla state: the held block reverts to its small, tilted mouth position and begins bobbing again.

To make FMBE props survive relogs and chunk travel, you have to re-broadcast the `/playanimation` commands periodically or trigger them when players enter the area. In a pure command-block build, creators usually place a repeating command block ticking every 20 to 60 ticks (`execute as @e[tag=fmbe] at @s if entity @a[r=64] run function ...`) so nearby clients continuously receive the pose packet. Because re-sending the exact same animation on the exact same controller name does not visibly reset the pose if the blend time is `0`, this keeps the prop stable.

If you are writing a full Behavior Pack with a Script API module or entity events, you should avoid running `/playanimation` every single tick on hundreds of foxes, as the network packet overhead will cause client lag and delayed chunk loading. Instead, throttle your refresh function to run once every few seconds, or use an entity `minecraft:environment_sensor` or Script API `entityLoad` / player dimension checks to fire the setup function only when the entity is newly simulated.

{
  "format_version": "1.16.0",
  "minecraft:entity": {
    "description": {
      "identifier": "minecraft:fox",
      "is_spawnable": true,
      "is_summonable": true,
      "is_experimental": false
    },
    "component_groups": {
      "wiki:fmbe_static_prop": {
        "minecraft:collision_box": {
          "width": 0.0,
          "height": 0.0
        },
        "minecraft:physics": {
          "has_gravity": false,
          "has_collision": false
        },
        "minecraft:pushable": {
          "is_pushable": false,
          "is_pushable_by_piston": false
        },
        "minecraft:damage_sensor": {
          "triggers": [
            {
              "Deals_damage": false
            }
          ]
        }
      }
    },
    "components": {
      "minecraft:type_family": {
        "family": [ "fox", "lightweight", "mob" ]
      }
    },
    "events": {
      "wiki:make_fmbe": {
        "add": {
          "component_groups": [ "wiki:fmbe_static_prop" ]
        }
      }
    }
  }
}

FMBE is a clever workaround, not a universal replacement for proper add-on architecture. Its primary strength is that it requires zero client-side downloads: a player joining a server or Realm without downloading a Resource Pack can still see custom 3D block arrangements, tilted pillars, miniature block models, and custom item displays because every animation and geometry used is already baked into the base game.

However, if your project already requires a custom Resource Pack (for example, if you have custom UI, custom sounds, or custom textures), you do not need to jump through the hoops of vanilla animation chaining on a fox. Instead, you can create a dedicated dummy entity in your Behavior Pack and give it a custom geometry and a custom animation in your Resource Pack that reads `query.mark_variant`, `query.skin_id`, or `query.property()` to control its scale and rotation directly and permanently—meaning it will never reset when chunks unload.

Keep entity count in mind as well. Even with AI stripped out, every FMBE prop is a live `minecraft:fox` actor in the world. Putting forty FMBE foxes in a single room to build a detailed chandelier is fine; putting four thousand of them across a city spawn to build custom roofs will degrade both server tick performance (actor iteration) and client frame rate (skeletal bone matrix calculations).

Applies to Minecraft Bedrock 1.16.100 and later (where the modern /playanimation command and Molang stop expressions were introduced). Works in current 1.20.x and 1.21.x releases without any experimental toggles required.

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