Molang vs. Java Predicates: Conditional Logic in Bedrock

In Java Edition data packs, conditional logic is heavily structured around JSON trees. If you want to check whether a player is sneaking, holding a specific item, and standing in rain, you build a predicate file in your data pack using conditions like entity_properties, location_check, and inverted terms. Alternatively, you inline those checks into an execute if data or execute if predicate command. The evaluation happens on the server tick, often triggered by a tick function or an advancement criteria.

Bedrock Edition does not have a dedicated predicate folder, nor does it expose raw entity NBT to commands or JSON files. Instead, Bedrock embeds logic directly into the fields where decisions are made using Molang (Minecraft Object Language). Molang is a lightweight scripting language designed originally for animations and particles, which has since expanded to drive server-side entity behaviors, block permutations, item rendering, and dialogue gates. Rather than referencing an external file that returns true or false, you write a mathematical or boolean string directly inside the JSON property you want to control.

Another fundamental difference is the execution context. Java predicates are strictly server-side data pack constructs (aside from simple model overrides in resource packs). In Bedrock, Molang runs on both the client (inside Resource Packs for animations, render controllers, and particles) and the server (inside Behavior Packs for entity filters, environment sensors, and block states). While the syntax is identical in both places, certain queries are restricted depending on whether the client knows about the underlying data.

Molang syntax is much closer to JavaScript or C than it is to JSON. Expressions evaluate to a single floating-point number. For boolean logic, a return value of 0.0 represents false, and any non-zero value (typically 1.0) represents true. You can use standard comparison operators (==, !=, <, >, <=, >=), logical operators (&& for AND, || for OR, ! for NOT), and the ternary conditional operator (condition ? true_value : false_value). This means a massive nested Java alternative predicate with multiple inverted blocks collapses into a single line of Molang.

Data in Molang is accessed through specific prefixes, which have short aliases used by almost all experienced developers. Queries (query. or q.) read game state, such as entity health, current dimension, time of day, or equipped items. Variables (variable. or v.) store read-write values attached to that specific entity or particle instance for the duration of a session or tick. Temp variables (temp. or t.) hold values only for the duration of a single expression evaluation, cleaning up immediately afterward. Contexts (context. or c.) provide read-only data passed down by a specific game event, such as the item currently being held in a render controller.

For simple expressions—which make up the vast majority of predicate replacements—you write a single line without a semicolon, and its result is implicitly returned. If you need to calculate intermediate values using temp variables or run multiple conditional branches, you wrap the expression in curly braces, end each statement with a semicolon, and explicitly use the return keyword at the end. Strings inside Molang queries are always wrapped in single quotes, because the Molang expression itself lives inside a JSON double-quoted string.

// Simple implicit return (checks if sneaking and below half health)
q.is_sneaking && (q.health / q.max_health) < 0.5

// Complex multi-statement block using temp variables and explicit return
{
  t.speed = q.ground_speed;
  t.is_moving_fast = t.speed > 4.5;
  return t.is_moving_fast && !q.is_in_water ? 1.0 : 0.0;
}

When you build a Behavior Pack entity in Bedrock, you will actually encounter two different systems for checking conditions: JSON Entity Filters and Molang Queries. This frequently confuses developers coming from Java. Entity Filters are JSON objects that look very similar to Java predicates—they use keys like test, subject, operator, and value, and can be grouped inside all_of, any_of, and none_of arrays. Historically, Bedrock used Entity Filters for all server-side AI components, while Molang was strictly for client-side Resource Packs.

In modern Bedrock versions, these two systems overlap through a specific filter test called has_property, as well as the ability to run Molang directly inside certain behavior components and animation controllers. However, many core AI components—such as minecraft:environment_sensor, minecraft:Interact, or minecraft:damage_sensor—still require a standard JSON filter block as their entry point. If you need to trigger an entity event when an entity enters water while holding a specific item, you can either build an all_of filter tree, or you can attach a server-side Animation Controller to the entity in the Behavior Pack and use pure Molang to fire the event or run slash commands.

Compare how you would check if an entity is currently on fire, not in water, and has a custom state active. In a Behavior Pack component that expects a filter, you write the structured filter object. In a Behavior Pack animation controller (which runs on the server and can execute commands and trigger component groups just like a Java tick function), you write a concise Molang query.

{
  "format_version": "1.10.0",
  "animation_controllers": {
    "controller.animation.custom_mob.combat_state": {
      "initial_state": "default",
      "states": {
        "default": {
          "transitions": [
            {
              "enraged": "q.is_on_fire && !q.is_in_water && q.health < (q.max_health * 0.5)"
            }
          ]
        },
        "enraged": {
          "on_entry": [
            "/effect @s speed 10 1 true",
            "/playsound mob.ravager.roar @a[r=16]"
          ],
          "transitions": [
            {
              "default": "!q.is_on_fire || q.is_in_water"
            }
          ]
        }
      }
    }
  }
}

In Java Edition, if you want to track a custom state on an entity—such as which phase a boss is in, or whether a villager has been spoken to—you usually add a scoreboard tag, set a scoreboard objective score, or merge custom NBT into the entity's Tags or data storage, then check it with a predicate. In Bedrock, scoreboards cannot be easily read by Resource Packs, and arbitrary NBT access does not exist. The modern, stable replacement for this workflow is Entity Properties.

Entity Properties are strongly typed variables (booleans, integers, floats, or string enums) declared inside the description block of a Behavior Pack entity file. Once declared, they persist with the entity across world saves just like NBT. If you set client_sync to true on a property, the server automatically synchronizes its value to the client whenever it changes. This is one of Bedrock's strongest features: you can change a property via a server-side event or command, and immediately read it in both server filters and client-side visual animations using q.property('namespace:property_name').

Below is a complete snippet of an entity description defining a custom integer property and a string enum property, followed by an environment sensor that modifies the property using an event when the entity is underwater. This completely replaces the Java pattern of running a repeating tick function that checks an execute if predicate condition to modify scoreboard values.

{
  "format_version": "1.20.80",
  "minecraft:entity": {
    "description": {
      "identifier": "wiki:custom_guardian",
      "is_spawnable": true,
      "is_summonable": true,
      "properties": {
        "wiki:charge_level": {
          "type": "int",
          "range": [0, 10],
          "default": 0,
          "client_sync": true
        },
        "wiki:stance": {
          "type": "enum",
          "values": ["idle", "defensive", "aggressive"],
          "default": "idle",
          "client_sync": true
        }
      }
    },
    "components": {
      "minecraft:health": {
        "value": 40,
        "max": 40
      },
      "minecraft:environment_sensor": {
        "triggers": [
          {
            "filters": {
              "all_of": [
                {
                  "test": "in_water",
                  "subject": "self",
                  "value": true
                },
                {
                  "test": "enum_property",
                  "domain": "wiki:stance",
                  "value": "idle"
                }
              ]
            },
            "event": "wiki:enter_defensive_stance"
          }
        ]
      }
    },
    "events": {
      "wiki:enter_defensive_stance": {
        "set_property": {
          "wiki:stance": "defensive",
          "wiki:charge_level": "q.property('wiki:charge_level') + 1"
        }
      }
    }
  }
}

Java resource packs use a predicates system inside item model JSON files to swap textures or geometry based on properties like custom_model_data, damage, pulling, or broken. For entities, vanilla Java does not natively support conditional geometry or texture swapping without third-party mods or riding invisible armor stands with custom item models.

Bedrock handles conditional visuals natively through Render Controllers and bone visibility in Geometry/Animation files, powered entirely by Molang. A Render Controller sits between your entity's resource definition (where you give short names to textures, materials, and geometries) and the rendering engine. Inside the Render Controller, you can use Molang ternaries or array lookups to dynamically pick which texture, model, or material to render on every frame based on the entity's state or synced properties.

Furthermore, within the part_visibility section of a Render Controller, you can toggle individual bones of a 3D model on and off using boolean Molang expressions. If a boss entity's wiki:stance property changes to aggressive on the server, the client's Render Controller immediately sees q.property('wiki:stance') == 'aggressive' evaluate to true, allowing it to swap the entity's skin to an angry texture and unhide armor spikes on its model without a single command or entity swap.

{
  "format_version": "1.8.0",
  "render_controllers": {
    "controller.render.custom_guardian": {
      "geometry": "Geometry.default",
      "materials": [
        {
          "*": "Material.default"
        }
      ],
      "textures": [
        "q.property('wiki:stance') == 'aggressive' ? Texture.aggressive : Texture.default"
      ],
      "part_visibility": [
        {
          "*": true
        },
        {
          "spikes_bone": "q.property('wiki:charge_level') >= 5"
        }
      ]
    }
  }
}

In Java Edition, block states control models via the blockstates JSON file, while server-side behavior based on block states requires checking location predicates or using execute if block commands. In Bedrock, custom blocks combine visual and behavioral state variations into a single file inside the Behavior Pack using the permutations array and Molang.

Each permutation entry in a Bedrock block file has a condition field that takes a Molang string. Here, you use q.block_state('namespace:state_name') to read the block's current state values. When the Molang condition evaluates to true, the components listed inside that permutation override the base components of the block. You can change collision boxes, light emission, friction, loot tables, or geometry visibility dynamically without writing external predicate files.

{
  "format_version": "1.20.80",
  "minecraft:block": {
    "description": {
      "identifier": "wiki:charge_lamp",
      "states": {
        "wiki:lit": [false, true],
        "wiki:power_level": [0, 1, 2, 3]
      }
    },
    "components": {
      "minecraft:destructible_by_mining": {
        "seconds_to_destroy": 2.0
      },
      "minecraft:light_emission": 0
    },
    "permutations": [
      {
        "condition": "q.block_state('wiki:lit') && q.block_state('wiki:power_level') >= 2",
        "components": {
          "minecraft:light_emission": 15
        }
      },
      {
        "condition": "q.block_state('wiki:lit') && q.block_state('wiki:power_level') == 1",
        "components": {
          "minecraft:light_emission": 7
        }
      }
    ]
  }
}

Core Molang expressions, queries, and Render Controllers apply to all modern Bedrock versions (format_version 1.8.0 and 1.10.0+ for RP files). Entity Properties (replacing the older experimental properties system) and q.block_state are fully stable without any experimental toggles in Bedrock 1.20.80 and newer.

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