Placeholders, Player Context, and Command Handoffs

Placeholder and player-context handling deserves its own page in Duck Blocks because a lot of live machines only make sense when the plugin knows who caused the action.

The built-in Duck Blocks tokens

The current placeholder resolver in Duck Blocks exposes these built-in tokens:

• {world}
• {x}
• {y}
• {z}
• {player}
• {target}
• {uuid}

The first four come from the trigger's center location. The player-side values only resolve when a real player context exists.

What each token means

Location tokens

• {world} = the trigger world name
• {x} = trigger block X
• {y} = trigger block Y
• {z} = trigger block Z

Use these when the command needs to know where the machine lives.

Player tokens

• {player} = activating player name
• {target} = same player-name context in the current build
• {uuid} = activating player UUID

Use these when the command or message should be tied to the person who actually caused the trigger.

Important rule: player context is not always present

This is one of the most important practical ideas in Duck Blocks.

A click-triggered control usually has a real player context. A redstone pulse or an always-running machine may not.

That means you should always ask:

• does this machine truly need a player name
• should it still run if no player context exists
• is the command being executed as console or player

The requirePlayerPlaceholder safeguard

Duck Blocks includes a real safeguard for this exact issue:

• the command surface exposes --require-player-placeholder
• the Redstone Advanced GUI exposes Require %player%
• the saved trigger stores requirePlayerPlaceholder

Use that safeguard when:

• the command list expects a player token
• the machine can be activated by redstone or another non-player source
• you would rather skip the run than fire a broken console command

In practice, this is one of the best protections you can turn on for redstone-driven per-player machines.

Example: safe player-dependent console flow

commands:
  - "lp user {player} permission set machine.reward"
redstoneEnabled: true
redstonePerPlayer: true
redstoneRange: 12.0
redstoneSkipIfEmpty: true
requirePlayerPlaceholder: true

This is the right style when the trigger should fire once for each nearby player, but only if a real player can actually be identified.

Waypoint action placeholders

Waypoint actions have their own practical placeholder use too. The in-game waypoint help surfaces these public values:

• {player}
• {uuid}
• {trigger}

That makes waypoint actions useful for:

• station arrival messages
• checkpoint rewards
• moving platform announcements
• route-based machine handoffs

Example: waypoint arrival message

msg: Welcome aboard, {player}
title: Station Arrived | DuckBlock {trigger}

That is a good fit for trains, lifts, and scripted moving set pieces.

PlaceholderAPI note

This build of Duck Blocks clearly resolves its own internal tokens and then hands the finished text into commands and action lines. It does not look like a first-class native PlaceholderAPI expansion is being registered directly by Duck Blocks itself in the current source.

That does not make the plugin less useful.

The normal public workflow is:

1. let Duck Blocks resolve its own trigger and player tokens
2. hand the finished command to the console, player, or another plugin

That is already enough for most real-world integration work.

Good uses for placeholder context

• reward the player who pressed a button
• send a private message or title to the activating player
• identify which machine or coordinate fired the action
• let redstone-driven logic affect all nearby players safely
• label station or route events inside moving structures

Bad uses for placeholder context

• assuming {player} will exist during every automated run
• building a redstone machine around player-only commands without the safeguard
• mixing too many context-sensitive commands into one trigger without testing each activation path

Best next pages

• command Authoring, Books, Command Files, and db: Action Lines
• activation Sources, Redstone, and Player Proximity
• redstone Advanced, Edge Modes, Range, and Player Context