Entity Dummy Components and Harmless Placeholders

When you first start building complex state machines inside an entity behavior file, it is tempting to invent your own component names inside a component group, such as "custom:is_sleeping" or "my_pack:phase_two". If you try this, the game's JSON parser will immediately flag it as an unrecognized component and throw a content log error when the entity spawns.

To work around this restriction, creators use two patterns that are informally called dummy components. The first is an empty component group, which holds no components at all and only exists to be checked by filters inside the Behavior Pack. The second is a harmless vanilla component—such as "minecraft:variant" or "minecraft:is_baby"—placed inside a component group solely for its side effects, like exposing a Molang query to the Resource Pack or firing an event after a delay.

If your state only needs to be read on the server side—for instance, within target selectors, environment sensors, or interaction filters—you do not need a component inside your component group at all. Bedrock allows you to define a component group as an empty JSON object {}.

When an event adds this empty group to the entity, nothing changes about the entity's physical behavior or attributes. However, the "is_family" filter cannot read component groups, so you must use the "has_component" filter? No—"has_component" checks for actual components. Instead, to check an empty component group or track a server-side state without changing behavior, the standard dummy component to put inside the group is "minecraft:type_family". By adding a custom family name to the entity when the group is active, any "is_family" filter in your entity file or command selectors can immediately detect the state.

{
  "format_version": "1.20.0",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:guard",
      "is_spawnable": true,
      "is_summonable": true
    },
    "component_groups": {
      "wiki:state_alerted": {
        "minecraft:type_family": {
          "family": [ "guard", "mob", "alerted_state" ]
        }
      }
    },
    "components": {
      "minecraft:type_family": {
        "family": [ "guard", "mob" ]
      },
      "minecraft:environment_sensor": {
        "triggers": [
          {
            "filters": {
              "all_of": [
                { "test": "is_family", "subject": "self", "value": "alerted_state" },
                { "test": "is_daytime", "value": true }
              ]
            },
            "event": "wiki:calm_down"
          }
        ]
      }
    },
    "events": {
      "wiki:become_alert": {
        "add": {
          "component_groups": [ "wiki:state_alerted" ]
        }
      },
      "wiki:calm_down": {
        "remove": {
          "component_groups": [ "wiki:state_alerted" ]
        }
      }
    }
  }
}

Behavior Pack components and family types are invisible to the client-side Resource Pack. If your custom entity needs to change its texture, geometry, or animation when it enters a specific behavior state, you can use a vanilla visual or data component that does nothing on its own unless your Resource Pack actively reads it.

Components like "minecraft:variant", "minecraft:mark_variant", and "minecraft:skin_id" accept any integer value. They have zero impact on AI or physics, making them ideal dummy data holders. Similarly, empty tag components like "minecraft:is_ignited", "minecraft:is_sheared", or "minecraft:is_saddled" act as instant boolean switches that you can read in animations and render controllers using their matching Molang queries.

Another classic dummy pattern uses "minecraft:timer" not as part of the entity's permanent logic, but inside a temporary component group to act as a delay node between two events. When an event adds the timer group, the countdown begins. Once the time expires, the timer fires a follow-up event that removes its own component group and executes the next step in the sequence.

For this to work reliably as a one-shot delay, set "looping" to false and make sure the triggered event removes the component group containing the timer. If you do not remove the group, adding it again later will not restart the countdown.

{
  "format_version": "1.20.0",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:turret",
      "is_spawnable": true,
      "is_summonable": true
    },
    "component_groups": {
      "wiki:overheated_delay": {
        "minecraft:is_ignited": {},
        "minecraft:timer": {
          "looping": false,
          "time": [ 5.0, 5.0 ],
          "time_down_event": {
            "event": "wiki:cool_down_complete",
            "target": "self"
          }
        }
      }
    },
    "components": {
      "minecraft:health": {
        "value": 20,
        "max": 20
      }
    },
    "events": {
      "wiki:trigger_overheat": {
        "add": {
          "component_groups": [ "wiki:overheated_delay" ]
        }
      },
      "wiki:cool_down_complete": {
        "remove": {
          "component_groups": [ "wiki:overheated_delay" ]
        }
      }
    }
  }
}

In modern Bedrock development, the official replacement for integer and boolean dummy components is the Entity Properties system (declared under "properties" in the entity description and read via "query.property"). Entity properties let you define named booleans, integers, floats, and enums with custom names, and they optionally sync to the client for Resource Pack queries without hijacking "minecraft:variant" or "minecraft:is_saddled".

However, dummy components are still practical when you need to bundle a state flag directly inside a component group alongside AI goals, or when you want a "minecraft:timer" to clean itself up automatically when a state ends. Watch out for unwanted vanilla side effects when choosing a boolean component: for example, "minecraft:is_baby" looks like a convenient boolean flag, but it often alters hitbox scaling, movement speed, or head bone rendering in ways you did not ask for. Stick to truly inert tags like "minecraft:is_sheared" or "minecraft:is_ignited" if you only want a visual signal.

Applies to all modern Bedrock versions (1.16.0 through 1.21+). No experimental toggles are required for vanilla dummy components or standard Entity Properties.

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