Assign Unique Scoreboard IDs to Entities and Players

Scoreboards in Bedrock Edition only store 32-bit signed integers, meaning you cannot copy an entity's internal UUID string into a score. To work around this limitation without using Script API, you maintain a single global counter on a fake player name and increment it every time an entity needs a new ID. That entity copies the current counter value into its own score, ensuring no two entities ever receive the same number.

The critical requirement of this pattern is that the increment and the assignment must happen one at a time, even if twenty entities spawn on the exact same tick. If you run a plain `/scoreboard players operation` across `@e` without restricting the target count, every unindexed entity will copy the same counter value before the counter has a chance to tick up.

By combining the `/execute as` subcommand with the `c=1` target selector argument, you force the game to process unindexed entities individually, or you let each entity drive its own assignment in sequence. In Bedrock, when `/execute as @e[...]` runs a `.mcfunction` file, the entire function executes from top to bottom for the first matched entity before starting over for the second matched entity. This execution order makes single-tick batch assignment completely reliable.

Before any IDs can be handed out, your behavior pack must create the scoreboard objective and initialize the fake player counter. Using a fake player name that begins with a hash symbol, such as `#next_id` or `.global_id`, guarantees that a real player with that name can never join the world and corrupt your counter. Furthermore, names starting with `#` are hidden from the sidebar display if you temporarily set the objective to `sidebar` while debugging.

Place the initialization commands inside a setup function that runs on world load, or wire it into `BP/functions/tick.json` alongside your main loop. Running `scoreboard objectives add` repeatedly is safe because Bedrock simply ignores the command if the objective already exists, though keeping it in a one-time setup function keeps your content log clean.

# Create the dummy objective for storing unique IDs
scoreboard objectives add id dummy "Unique ID"

# Ensure the global counter exists and starts at 0 if not already set
scoreboard players add #next_id id 0

To automatically assign a unique ID to every player the moment they join the world, you need two small functions: a router function registered in `tick.json` and a worker function that performs the math. The router checks for any player who lacks the `has_id` tag and runs the worker function `as` that player.

Inside the worker function, `@s` refers to the single player currently being processed. The function first adds `1` to `#next_id`, then uses the `=` operator in `scoreboard players operation` to copy the value of `#next_id` onto `@s`. Finally, it applies the `has_id` tag so the player is skipped on all future ticks.

Because Bedrock executes the entire called function for the first player matched by `@a[tag=!has_id]` before moving to the next player in the selector list, even ten players joining simultaneously on a fresh server will receive clean, sequential numbers from `1` to `10` within the same game tick.

# Increment the master counter by 1
scoreboard players add #next_id id 1

# Copy the new counter value to the current entity or player
scoreboard players operation @s id = #next_id id

# Mark this target so it never receives a second ID
tag @s add has_id

To make the assignment automatic, create a main tick function that invokes `id/assign_single` for any unindexed player or specific custom entity, and register that main function in `BP/functions/tick.json`. Avoid running the assignment across `@e[tag=!has_id]` without a `type` or `family` filter; otherwise, every dropped item, arrow, and experience orb in the world will consume an ID and bloat the world's scoreboard database.

Instead, target players directly with `@a[tag=!has_id]` and target only the custom entities that actually need linking by using a dedicated request tag such as `tag=needs_id`. When your custom entity spawns, you can grant it the `needs_id` tag through a spawn event in its behavior file, and the tick function will immediately assign its score and remove the request tag.

{
  "values": [
    "id/tick"
  ]
}

Once both a player and a secondary entity have scoreboard capability, you can link them together by copying the player's unique ID into a separate objective on the child entity, such as `owner_id`. When you want the child entity to teleport to its owner or apply an effect to them, you compare their scores using `scoreboard players operation`.

Because target selectors cannot evaluate a dynamic variable inside `scores={id=...}`, the standard Bedrock recipe for finding a linked partner is the subtraction test. You copy the child entity's `owner_id` to a temporary score on every candidate player, subtract each player's own `id` from that temporary score, and select the one player whose result equals `0`.

The function below shows both the tick router that triggers `id/assign_single` and the subtraction pattern used to locate the matching owner during gameplay.

# Ensure the objective exists
 scoreboard objectives add id dummy
scoreboard objectives add temp_match dummy

# Assign unique IDs to any new players
execute as @a[tag=!has_id] run function id/assign_single

# Assign unique IDs to custom entities that requested one
execute as @e[tag=needs_id,tag=!has_id] run function id/assign_single
tag @e[tag=needs_id,tag=has_id] remove needs_id

# Example link check: executed AS a pet or marker that has an 'id' score matching its owner's 'id'
# Copy this entity's ID to all players on the temp_match objective
# execute as @e[type=minecraft:armor_stand,tag=linked_marker] run scoreboard players operation @a temp_match = @s id
# Subtract each player's own ID from their temp_match score
# execute as @e[type=minecraft:armor_stand,tag=linked_marker] as @a run scoreboard players operation @s temp_match -= @s id
# Whoever has temp_match == 0 is the owner of this marker
# execute as @e[type=minecraft:armor_stand,tag=linked_marker] at @a[scores={temp_match=0}] run tp @s ~ ~2 ~

If you are creating a custom entity in your behavior pack and want it to receive a unique ID the instant it enters the world, you do not even need to wait for the global tick loop. You can invoke `id/assign_single` directly inside the `minecraft:entity_spawned` event using a `queue_command` response.

When `queue_command` runs on an entity event, the execution context `@s` is already set to the newly spawned entity. It queues the function to run on the upcoming tick with `@s` bound to that exact instance, guaranteeing it gets a unique score before your gameplay systems interact with it.

{
  "format_version": "1.20.40",
  "minecraft:entity": {
    "description": {
      "identifier": "example:custom_drone",
      "is_spawnable": true,
      "is_summonable": true
    },
    "components": {
      "minecraft:physics": {},
      "minecraft:health": {
        "value": 20,
        "max": 20
      }
    },
    "events": {
      "minecraft:entity_spawned": {
        "queue_command": {
          "command": [
            "function id/assign_single"
          ]
        }
      }
    }
  }
}

Applies to Minecraft Bedrock 1.19.50 and newer (uses the modern /execute syntax). No experimental toggles are required.

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