Activation Sources, Redstone, and Player Proximity

Duck Blocks can fire from much more than a click. The activation system is the reason the plugin can behave like a machine engine instead of a simple button tool.

The activation families

Direct player interaction

• CLICK
• ACTIVATE

Use these when a player intentionally uses the block.

Continuous or loop-style behavior

• ALWAYS
• PLAYER_STAY_RADIUS

Use these when the machine should keep doing something while conditions remain true.

Redstone-driven behavior

• REDSTONE_ON
• REDSTONE_OFF
• REDSTONE_PULSE

Use these when the machine should react to circuitry instead of direct interaction.

Proximity and player-count behavior

• PLAYER_ENTER_RADIUS
• PLAYER_EXIT_RADIUS
• PLAYER_COUNT_AT_LEAST
• PLAYER_COUNT_AT_MOST
• PLAYER_COUNT_EXACT

Use these when the block should respond to traffic, crowds, or presence.

Where these activation rules show up

In the current public build, activation logic appears in several practical places:

• normal trigger interaction
• redstone-driven machines
• timeline triggers
• travel start rules
• ModelEngine action rules

That is why learning activation once pays off everywhere else in Duck Blocks.

The rule fields that shape activation

The activation-rule layer is built around a small set of practical fields:

• range
• playerCount
• cooldownMs
• hysteresisTicks

These matter because they stop proximity logic from becoming noisy or unstable.

Redstone settings that matter most

Duck Blocks uses event-driven redstone behavior. The practical controls are:

• enabled or disabled
• edge mode
• debounce
• per-player targeting
• range
• max targets
• skip if empty
• require player placeholder
• anchor selection

The detailed tuning page for those controls is redstone Advanced, Edge Modes, Range, and Player Context.

What each redstone control really does

Edge mode

Choose whether the block should react on:

• power-up only
• power-down only
• both changes

Debounce

This is the safety delay that stops noisy or rapidly flickering redstone from firing too often.

Per-player and range

Use these when the redstone machine should execute once for each nearby player instead of once globally.

Skip-if-empty

Use this when a per-player redstone flow should do nothing if nobody is in the target area.

Require player placeholder

Use this safeguard when the machine only makes sense if the command flow actually has a real player context.

Good use cases

A simple adventure-map button

Use CLICK with a cooldown.

A piston door or signal machine

Use REDSTONE_ON or BOTH with a sensible debounce.

A room ambience machine

Use PLAYER_ENTER_RADIUS, PLAYER_EXIT_RADIUS, or a NEARBY timeline.

A crowd-gated objective

Use PLAYER_COUNT_AT_LEAST or PLAYER_COUNT_EXACT with hysteresis so the machine does not flap on every tiny count change.

ModelEngine note

ModelEngine action rules use the same activation-rule philosophy. That means once you understand the activation surface here, the ModelEngine action layer becomes much easier to reason about.

Best next pages

• trigger Editor, Core Controls, and Machine Layout
• redstone Advanced, Edge Modes, Range, and Player Context
• travel Paths, Walkable Platforms, and Rideable Structures
• displays, Hitboxes, and ModelEngine