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.
Duck Blocks separates the visible part of a machine from the part the player actually interacts with. That split is why you can make clean props, readable buttons, and large moving structures without forcing the click area to match the visible art exactly.
The modern visual modes
The main display-driven render paths are:
DISPLAY_TEXTDISPLAY_ITEMDISPLAY_BLOCK
These are the preferred modern modes for most public content.
What the display editor controls
The display editor gives you direct control over:
- render mode
- hitbox width and height
- responsive behavior
- text, held item, or block data
- scale
- billboard mode
- interpolation duration
- interpolation delay
- hide and show
- visual offsets and hitbox offsets
- visual rotation and hitbox rotation
That means you can keep a prop readable and clickable without making the visual itself awkward.
Visual versus hitbox
This is one of the most important Duck Blocks concepts.
The visual answers:
- what players see
- how large the prop looks
- whether it spins, floats, or hides
The hitbox answers:
- where the player can click
- how forgiving the interaction should be
- whether the control feels precise or generous
Do not assume they should always be identical.
Good design habits
- make kiosk buttons and terminals easier to click than they look
- keep decorative floating items slightly above the interaction box
- use interpolation when the visual needs smooth client motion
- hide or shrink the visual only when the machine itself should stay playable
ModelEngine support
Duck Blocks has optional soft compatibility with ModelEngine. It does not require ModelEngine to load, but it can cooperate with it when present.
The main public ModelEngine ideas are:
- owned binding
- attached binding
- model id
- default bone
- show or hide the native display
- default idle animation
- per-action activation rules
Owned versus attached
Owned
Use owned mode when the DuckBlock should own the model relationship directly.
Attached
Use attached mode when the model is being bound onto an existing host relationship and you want the block to cooperate with that structure instead of fully replacing it.
Helpful ModelEngine commands
The admin flow includes:
/duckblock modelengine gui
/duckblock modelengine status
/duckblock modelengine link
/duckblock modelengine unlinkThose are the commands to learn first before you try to build larger model-driven machines.