
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.
In-Game Authoring
Build DuckBlocks live through the admin menu, trigger editor, display editor, and machine-by-machine editor flow.
Placeholders and Context
Understand player context, built-in tokens, and how Duck Blocks hands finished commands into the rest of the server.
Trigger Logic and Motion
Control how DuckBlocks fire, sequence, move, and carry players through the world.
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.
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
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:
execModeexecDelayMscooldownMsoneTime
Use them this way:
CONSOLEwhen the server should own the actionPLAYERwhen 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
- activation Sources, Redstone, and Player Proximity
- redstone Advanced, Edge Modes, Range, and Player Context
- animations, Effects, and the Timeline Orchestrator
- command Authoring, Books, Command Files, and
db:Action Lines - placeholders, Player Context, and Command Handoffs
- effects YML: Sounds, ParticleFX, and Combo Presets

