Molang Queries Reference Table

Every query begins with the prefix query. or its shorthand q. followed by the query name in snake_case. Both forms are completely interchangeable across resource packs and behavior packs, though q. is generally favored in complex expressions to keep character counts down and improve readability inside JSON strings.

Most Molang queries return a floating-point number. When a query represents a true or false condition, it returns 1.0 for true and 0.0 for false. Because Molang treats any non-zero value as truthy and 0.0 as falsy, you can drop boolean queries directly into animation controller transition arrays or ternary operators without comparing them to 1.0 first.

Some queries accept arguments inside parentheses, such as a slot name, an equipment hand, a block face index, or a custom property identifier. Queries that take no arguments can be written with or without empty parentheses in older format versions, though modern schemas and complex math expressions are safest when you omit empty parentheses on argument-free queries or follow the exact signature.

// Boolean check using shorthand alias
q.is_on_ground && !q.is_in_water

// Numeric query driving a sine wave for leg swing
math.cos(q.modified_distance_moved * 38.17) * q.modified_move_speed * 45.0

// Parameterized query reading an entity property
q.property('custom:charge_state') == 2

The most frequently used queries inspect an entity's physical movement, health, and immediate action flags. Animation files rely heavily on modified movement queries so that walk cycles speed up or slow down naturally when the entity is affected by Speed or Slowness effects, or walks across soul sand.

State flags like is_baby, is_tamed, and is_sheared mirror the components active in the behavior pack. When a behavior pack adds or removes a component group containing minecraft:is_baby or minecraft:is_tamed, the corresponding query flips on the next client tick, allowing render controllers and animations to react immediately.

To drive client-side visuals from server-side behavior logic, you need queries that cross the network boundary. Historically, creators relied on integer components like minecraft:variant, minecraft:mark_variant, and minecraft:skin_id. These remain completely functional and are still the quickest way to select an index from a texture array in a render controller.

For modern packs, Entity Properties (defined inside the behavior pack entity description) are much cleaner and do not collide with vanilla component usage. You read them on both server and client using q.property('namespace:property_name'), provided you set client_sync to true in the property definition. If an entity returned by a query holds an enum string property, you compare it against a single-quoted string literal.

Timing queries keep procedural animations and particle curves smooth across different frame rates. Inside animations and animation controllers, q.anim_time tracks how many seconds have elapsed since the current animation or controller state began playing. Outside of animations, q.life_time gives the total age in seconds of the entity or particle emitter since it spawned on the client.

When building custom blocks or behavior pack filters that inspect the world, q.block_state('namespace:state_name') reads the current value of a custom or vanilla block state. In entity equipment checks, q.is_item_name_any lets you test whether a specific item identifier is held in a hand or worn in an armor slot.

The two examples below show where Molang queries sit in real pack files. The first is a client animation controller that switches between idle, walk, and attack states using movement and property queries. The second is a custom block definition that uses q.block_state inside a permutation condition to change light emission when toggled.

{
  "format_version": "1.10.0",
  "animation_controllers": {
    "controller.animation.golem_guard.move": {
      "initial_state": "idle",
      "states": {
        "idle": {
          "animations": [ "idle_pose" ],
          "transitions": [
            { "walk": "q.ground_speed > 0.15 && q.is_on_ground" },
            { "enraged": "q.property('my_pack:stance') == 'aggressive'" }
          ]
        },
        "walk": {
          "animations": [ "walk_cycle" ],
          "transitions": [
            { "idle": "q.ground_speed <= 0.15 || !q.is_on_ground" },
            { "enraged": "q.property('my_pack:stance') == 'aggressive'" }
          ]
        },
        "enraged": {
          "animations": [ "enraged_roar" ],
          "transitions": [
            { "idle": "q.property('my_pack:stance') != 'aggressive' && q.anim_time >= 1.5" }
          ]
        }
      }
    }
  }
}

When writing a behavior pack block file, the condition field inside each entry of the permutations array is a Molang string. Here, entity queries are out of scope because there is no actor context; instead, you are restricted to block queries like q.block_state.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "my_pack:lamp_post",
      "states": {
        "my_pack:lit": [ false, true ]
      }
    },
    "components": {
      "minecraft:destructible_by_mining": {
        "seconds_to_destroy": 2.0
      },
      "minecraft:light_emission": 0
    },
    "permutations": [
      {
        "condition": "q.block_state('my_pack:lit') == true",
        "components": {
          "minecraft:light_emission": 15
        }
      }
    ]
  }
}

Applies to Minecraft Bedrock 1.19.0 through 1.21+. Core movement, state, block_state, and entity property queries are completely stable and require no experimental toggles.

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