Skip to main content
Duck Blocks wiki

Wiki

Duck Blocks Wiki

In-world machines, trigger systems, moving structures, redstone logic, and the public Duck Blocks authoring workflow.

Getting Started

Start here for first boot, the file split, server-wide defaults, and the real saved trigger shape.

Placeholders and Context

Understand player context, built-in tokens, and how Duck Blocks hands finished commands into the rest of the server.

YML File Guides

Jump straight into the reusable preset files that make a large Duck Blocks library maintainable.

Runtime and Troubleshooting

Understand what gets saved, what the carry logs mean, and how to troubleshoot live Duck Blocks cleanly.

In-Game Authoring

Trigger Editor, Core Controls, and Machine Layout

Learn the actual menu map for one DuckBlock and which branch to open when the machine needs logic, visuals, motion, or redstone work.

The trigger editor is where one DuckBlock becomes a real machine. It is the most important menu in the plugin because almost every major system branches out from here.

The real editor branches

The current trigger editor gives you direct access to:

  • commands
  • teleport and highlight tools
  • execution mode
  • cooldown
  • delay
  • one-time behavior
  • redstone and redstone advanced
  • title and label
  • display and hitbox
  • move and rotate tools
  • travel paths
  • animations and effects
  • ModelEngine
  • delete

That means you should think of the trigger editor as the control room for one machine, not just a command list.

The editor jobs that matter most

Commands

This is where the machine's actual action list lives. Open it whenever the logic itself needs to change.

Execution mode, cooldown, delay, and one-time

These shape how often the machine can fire and who owns the run.

Redstone and redstone advanced

These turn the machine into a real circuitry component instead of just a clickable object.

Display and hitbox

These decide what the machine looks like and how forgiving it is to use.

Move and rotate

These are live placement tools for visual and interaction alignment.

Travel paths

This is the moving-structure layer. Do not treat it like a minor toggle.

Animations and effects

This is where idle motion, timelines, particles, sound design, and scripted feedback start to stack together.

ModelEngine

This is the optional bridge when the machine needs more than native display entities.

Commands versus internal action lines

Duck Blocks supports normal commands and its own internal db: action lines.

Normal commands

Use normal commands when you want to talk to:

  • the server console
  • player command flow
  • other plugins
  • gamemode systems
  • scoreboard, quest, economy, or teleport commands

Internal db: lines

Use db: lines when the behavior belongs inside Duck Blocks itself:

  • sounds
  • particles
  • particle shapes
  • messages
  • action bars
  • titles
  • display visibility and scale changes
  • console or player-command wrappers

Example machine command list

YAML
commands:
  - "say {player} pressed the station control."
  - "db:sound BLOCK_PISTON_EXTEND vol=1.0 pitch=1.0 audience=nearby mode=origin range=24"
  - "db:particlefx ring ELECTRIC_SPARK 1.4 96 0.0 0.0"
  - "db:actionbar Powering up..."

This is a good example of the mixed style Duck Blocks is built for: one trigger can run server logic and its own audio-visual feedback together.

Core control settings

These four controls shape how the block behaves over time:

  • execMode
  • execDelayMs
  • cooldownMs
  • oneTime

Use them this way:

  • CONSOLE when the server should own the action
  • PLAYER when the player's own command context matters
  • delay when the block should stage an action instead of firing instantly
  • cooldown when the block should not be spammed
  • one-time when the block is part of a single-use adventure or event flow

Why this page is an overview, not the whole story

The trigger editor is too large to explain honestly in one page. Use this page as the menu map, then go deeper into the specialized pages for the part you are actively editing.

Linking DuckBlocks together

Duck Blocks become much stronger when blocks cooperate instead of staying isolated.

Common ways to connect one DuckBlock to another:

  • use one block's commands to trigger a shared server-side action
  • use redstone to chain logic between physical machine pieces
  • let one block handle control while another handles travel or ambience
  • use waypoint actions on moving blocks to fire commands at specific path moments

This is how you build trains, elevators, scripted doors, moving islands, and larger world systems without forcing one trigger to contain every effect.

Best next pages