Redstone Advanced, Edge Modes, Range, and Player Context

The Redstone Advanced menu is where a simple powered trigger becomes a reliable machine component instead of a flaky contraption.

What the Redstone Advanced menu actually controls

The current in-game Redstone Advanced editor exposes these real controls:

• redstone enabled
• edge mode
• per-player targeting
• skip-if-empty
• require player placeholder
• debounce time
• range
• max targets
• anchor selection
• attached hitbox tools for block triggers

This is the menu to learn if you want Duck Blocks to cooperate with real circuitry.

Edge modes

Duck Blocks supports three public edge modes:

• ON
• OFF
• BOTH

Use them this way:

• ON for power-up behavior
• OFF for power-down behavior
• BOTH when either transition should matter

Most control panels, doors, and station buttons are cleaner on ON. Most state watchers and toggled machines need more thought.

Debounce

redstoneDebounceMs is the safety gap between valid firings.

Increase it when:

• your circuit flickers
• your machine is heavy enough that duplicate pulses feel wrong
• a piston, observer, or clock chain is too noisy

Keep it lower only when the machine really needs very rapid response.

Per-player redstone

Redstone does not have to mean one global run.

The advanced editor supports:

• redstonePerPlayer
• redstoneRange
• redstoneMaxTargets
• redstoneSkipIfEmpty

That combination lets one powered machine run once per nearby player instead of once globally. This is one of the strongest features in Duck Blocks for adventure maps, event areas, and objective machines.

Example: area-powered reward machine

redstoneEnabled: true
redstoneEdge: ON
redstoneDebounceMs: 250
redstonePerPlayer: true
redstoneRange: 12.0
redstoneMaxTargets: 16
redstoneSkipIfEmpty: true
requirePlayerPlaceholder: true

This is the shape to start from when a powered area should affect each nearby player separately.

What skip if empty is really for

redstoneSkipIfEmpty keeps the machine honest.

If the machine is supposed to do player-specific work and there are no valid targets, skipping is usually better than firing empty logic into the console.

What require player placeholder is really for

This flag protects player-sensitive command lists.

Turn it on when:

• the command uses {player}, {target}, or {uuid}
• the trigger may be activated by redstone with no direct clicker
• the safer choice is to skip the action entirely if no real player context exists

Anchor selection

The Redstone Advanced menu can set the machine's anchor from the block you are looking at.

Use that when:

• the visible machine is offset from the real redstone source
• one decorative machine should listen to a different hidden block
• you are building a hybrid prop where the logic source and the visual source are not the same object

This is one of the easiest ways to make larger world machines feel clean.

Attached hitboxes for block triggers

Block-based DuckBlocks can also expose attached hitbox tools from the advanced redstone surface.

That matters because block triggers can stay anchored to a real block while still getting a cleaner interaction area in front of the player.

Use this when:

• the machine is visually small but should be easy to use
• the machine is decorative and the actual clickable zone should sit nearby
• you want a logic block to remain hidden while the interactive surface stays readable

Good redstone patterns

Simple door or machine pulse

• ON
• moderate debounce
• no per-player logic

Crowd gate

• ON or BOTH
• per-player on
• range set
• skip-if-empty on
• placeholder safeguard on if rewards or player names are involved

Decorative machine with hidden circuitry

• anchor set to the real circuit block
• attached hitbox if the interaction point should be elsewhere

Best next pages

• placeholders, Player Context, and Command Handoffs
• activation Sources, Redstone, and Player Proximity
• duckblocks YML: Trigger Layout and Live Examples