Travel Paths, Walkable Platforms, and Rideable Structures

Travel paths are where Duck Blocks stops being "a trigger that plays an effect" and starts becoming a moving world system.

This is the layer that lets you build:

• elevators
• trains
• moving platforms
• rideable machines
• drifting islands
• moving props and patrol routes

The travel model

Travel is built around:

• a start trigger
• a travel mode
• movement speed
• a waypoint list
• optional walkable and mountable behavior
• optional waypoint actions

Travel triggers

The live travel layer supports:

• CLICK
• REDSTONE
• ALWAYS
• MANUAL

Use MANUAL when a builder or admin wants direct control. Use CLICK or REDSTONE when the machine should start from an event. Use ALWAYS only when the structure is meant to keep moving on its own.

Travel modes

The main movement patterns are:

• LOOP
• ADVANCE_ON_TRIGGER
• PING_PONG

Use them this way:

• LOOP for repeated circulation
• ADVANCE_ON_TRIGGER for step-by-step machines and puzzle devices
• PING_PONG for back-and-forth travel such as shuttles or lifts

The path authoring flow

Duck Blocks gives you two practical ways to build a path:

• add waypoints one by one in the GUI
• enter Path Builder Mode and edit them in the world with hotbar tools
• use quick-add buttons for your current position or the DuckBlock anchor

For larger moving structures, the in-world path builder is usually the better choice.

Waypoint actions

Each waypoint can hold its own actions and delay.

That means the machine can do something special at one exact path point, such as:

• play a sound
• fire a message
• show a title
• run a console command
• run a player command

The public placeholder surface there includes:

• {player}
• {uuid}
• {trigger}

Walkable structures

Travel becomes a true moving platform when you enable:

• walkable
• walk radius and height controls
• a walk platform type
• a carry mode

The walk platform type decides how Duck Blocks builds the collider layer for the moving structure.

Your live config already shows two important real-world patterns:

• a smaller walkable moving block with walkable: true, carryMode: SMART, and no mount
• a larger moving platform that combines walkable, SMART carry, levitation assist, and mountable: true

Mountable structures

Travel becomes a rideable machine when you also enable:

• mountable
• mountYOffset
• mountSneakToMount

That is a good fit when the player should be attached to the machine instead of freely walking around on it.

Carry modes

The carry mode is one of the biggest feel settings on a moving platform. The public options include:

• OFF
• VELOCITY
• COLLISION
• SMART
• TELEPORT_DELTA

In practice:

• OFF means the structure moves but does not help carry the player
• VELOCITY is the simple motion handoff
• SMART is the higher-end moving-platform mode and the one your live server is already using heavily

Example: a rideable platform

travel:
  enabled: true
  trigger: CLICK
  mode: LOOP
  speed: 1.5
  smooth: true
  walkable: true
  walkRadiusX: 1
  walkRadiusZ: 1
  walkHeight: 1
  walkPlatformType: COLLIDER_SHULKERS
  carryMode: SMART
  walkLevitationAssist: true
  mountable: true
  mountSneakToMount: true

That is the family of settings you use for a simple rideable platform, convoy cart, or basic train car.

Example builds to think in

Elevator

• short waypoint stack
• PING_PONG or ADVANCE_ON_TRIGGER
• walkable on
• no mount needed

Train

• long loop
• walkable on
• SMART carry
• waypoint actions for station sounds or announcements

Floating island

• ALWAYS or manual start
• large walk surface
• nearby-only ambience via timelines

If movement feels wrong

Read admin Runtime, State, and Live Troubleshooting and look at the carry debug logs before you keep guessing at the settings. Terms like TOP_SURFACE, sink, peek, and sessionColliderCount are there specifically to help you understand why a moving structure feels wrong.

If you want the actual menu-by-menu authoring path, read travel GUI, Path Builder, Waypoints, and Carry.