DuckBlocks YML: Trigger Layout and Live Examples

duckblocks.yml is the actual machine library. Every trigger you create in the GUI eventually lands here.

That means this file is the bridge between the in-game editor and the durable content pack you can version, move, or review.

Top-level file shape

schema: 9
triggers:
  - sid: 1
    commands: [item]
    execMode: CONSOLE

The file has a schema number and then a trigger list. Everything else is per-trigger data.

The trigger fields that matter most

Most public Duck Blocks work can be understood in these groups:

Trigger behavior

• commands
• execMode
• execDelayMs
• cooldownMs
• cooldownScope
• oneTime
• oneTimeScope
• title

Redstone behavior

• redstoneEnabled
• redstoneEdge
• redstoneDebounceMs
• redstonePerPlayer
• redstoneRange
• redstoneMaxTargets
• redstoneSkipIfEmpty
• requirePlayerPlaceholder

Visual and hitbox behavior

• renderMode
• interactionWidth
• interactionHeight
• displayText
• displayItem
• displayBlockData
• displayScale
• displayBillboard
• displayInterpolationDuration
• offsets and rotations

Advanced systems

• animations
• timelines
• travel
• modelEngine

Those fields are the reason Duck Blocks scales beyond simple buttons. They are also the fields most worth learning through the GUI first and by hand later.

Example: a simple visible trigger

triggers:
  - sid: 3
    commands:
      - "db:message You found the control panel."
      - "db:sound UI_BUTTON_CLICK vol=1.0 pitch=1.0 audience=player mode=origin range=0"
    execMode: CONSOLE
    cooldownMs: 0
    oneTime: false
    redstoneEnabled: false
    renderMode: DISPLAY_ITEM
    interactionWidth: 1.4
    interactionHeight: 1.4
    displayScale: 1.0

This is the correct style when you only need a visible prop that reacts to interaction.

Example: a moving display block

Your live Duck Blocks config already shows the larger travel structure clearly:

travel:
  enabled: true
  trigger: CLICK
  mode: LOOP
  speed: 1.5
  smooth: true
  activeRangeBlocks: 128.0
  walkable: false
  mountable: false
  waypoints:
    - x: 70.93
      y: 2.96
      z: 893.17
    - x: 68.75
      y: 2.88
      z: 890.5

That is the shape you use for moving props, looping patrol paths, and environmental machines.

Example: a rideable moving structure

Your live file also shows the more advanced platform shape:

travel:
  enabled: true
  mode: LOOP
  walkable: true
  walkRadiusX: 1
  walkRadiusZ: 1
  walkYOffset: 0
  walkPlatformType: COLLIDER_SHULKERS
  carryMode: SMART
  walkLevitationAssist: true
  mountable: true
  mountSneakToMount: true

This is the family of settings that turns a moving display into a structure players can stand on or ride.

Example: a live animated nearby machine

Your live file also shows the layered style Duck Blocks is built for:

animations:
  - name: "Spin - Always"
    type: SPIN
    mode: ALWAYS
  - name: "Pop - On Activate"
    type: POP
    mode: ACTIVATE
timelines:
  - name: sound
    enabled: true
    trigger: NEARBY
    loop: true
    loopDelayTicks: 1
    range: 5.0
    steps:
      - type: EFFECT_LINE
        line: "db:sound BLOCK.POWDER_SNOW.PLACE vol=2.15 pitch=0.45 range=25 oy=0.10"

This is the kind of split that keeps a machine readable:

• animations for idle or activation motion
• timelines for staged nearby behavior
• db: lines for the actual local feedback

How to think about YAML edits safely

The safest workflow is:

1. create or edit the block in the GUI
2. confirm it works in-game
3. read the saved YAML
4. make careful hand edits only when you now understand the saved shape

That protects you from writing giant blocks of YAML without knowing what the editor would have produced.

Best next pages

• trigger Editor, Core Controls, and Machine Layout
• command Authoring, Books, Command Files, and db: Action Lines
• activation Sources, Redstone, and Player Proximity
• travel Paths, Walkable Platforms, and Rideable Structures