Animations, Effects, and the Timeline Orchestrator

Duck Blocks has three different motion-and-feedback layers. Keeping them separate is the key to building machines that feel useful without turning the config into a mess.

The three layers

Animations

Animations are lightweight motion behavior attached directly to one DuckBlock's visual.

Use them for:

• floating props
• spinning collectibles
• pop-in and pop-out emphasis
• nearby-only movement that wakes up when players approach

Effects

Effects are the db: internal action lines and the preset library built on top of them.

Use them for:

• sounds
• titles and action bars
• particles
• particle shapes such as rings, spirals, beams, cubes, and shockwaves
• quick display actions like hide, show, scale, or text swaps

Timelines

Timelines are the sequence layer.

Use them when you want:

• a staged cinematic reveal
• repeated nearby ambience
• a click or redstone event that runs multiple steps in order
• a machine that feels scripted instead of instant

When to use each layer

If the effect should happen every tick or as a simple idle motion, use animations.

If the effect should happen once as a sound burst, particle line, or message, use effect lines.

If the effect should happen in steps with waits, loops, or repeated triggers, use a timeline.

Timeline triggers

The live Duck Blocks timeline layer supports these trigger styles:

• CLICK
• REDSTONE
• ACTIVATE
• ALWAYS
• NEARBY

That split matters:

• ALWAYS is for constant loops
• NEARBY is for ambience that should only run when players are near
• CLICK, REDSTONE, and ACTIVATE are for event-driven sequences

Timeline step types

The current public step families are:

• EFFECT_LINE
• SPIN

EFFECT_LINE is the workhorse. It lets you sequence any internal effect line or preset-driven behavior. SPIN is the dedicated visual rotation step.

Example: a nearby energy pedestal

This live-style timeline shape is a good example of a nearby loop:

timelines:
  - name: Nearby Energy Ring
    enabled: true
    trigger: NEARBY
    loop: true
    loopDelayTicks: 20
    range: 5.0
    steps:
      - type: EFFECT_LINE
        waitTicks: 0
        line: "db:particlefx ring ELECTRIC_SPARK 1.3 96 0.90 0.0"
      - type: EFFECT_LINE
        waitTicks: 0
        line: "db:particlefx ring ELECTRIC_SPARK 1.5 110 1.20 0.0"
      - type: EFFECT_LINE
        waitTicks: 0
        line: "db:sound ITEM.ARMOR.EQUIP_GOLD vol=1.15 pitch=1.20 range=20"

That is much cleaner than hard-wiring the same sound and particle burst into several different blocks manually.

Building multi-block machines

Duck Blocks become much more useful when you treat one block as a coordinator and the others as specialists.

A common structure is:

• one visible control block players interact with
• one or more hidden logic blocks for redstone or timing
• one moving block or platform for travel
• one effect-heavy block for ambience or spectacle

The coordination path can be:

• console commands
• player commands
• redstone state changes
• waypoint actions
• matching preset libraries in animations.yml and effects.yml

That means you do not need to cram every function into one trigger.

Good authoring order

1. Build the trigger and confirm it fires.
2. Add one effect line.
3. Add one animation if the prop needs idle motion.
4. Only then add a timeline if the machine needs sequencing.
5. Split large machines across multiple cooperating DuckBlocks instead of forcing one trigger to do everything.

Where to go deeper

• trigger Editor, Commands, Effects, and Placeholders
• travel Paths, Walkable Platforms, and Rideable Structures
• animations YML: Motion Presets and When to Use Them
• effects YML: Sounds, ParticleFX, and Combo Presets