Travel GUI, Path Builder, Waypoints, and Carry

The Travel GUI is where Duck Blocks turns into a moving-world tool. This is the menu to learn if you want trains, elevators, drifting props, moving platforms, or rideable structures that can carry players cleanly.

What the Travel menu actually contains

The current in-game Travel menu exposes these practical controls:

• enabled
• start or advance trigger
• mode
• smooth movement
• persistent
• active range
• speed
• waypoints
• start or stop
• add waypoint at your position
• walk and mount hitbox settings
• path builder mode
• add waypoint at the DuckBlock position

This is already a large authoring surface. Treat it like its own subsystem, not just one toggle inside the trigger editor.

Start trigger versus mode

Duck Blocks separates the reason movement begins from the way the path behaves after it starts.

Start trigger

The current travel start families include:

• CLICK
• REDSTONE
• ALWAYS
• MANUAL

Travel mode

The main movement patterns include:

• LOOP
• PING_PONG
• ADVANCE_ON_TRIGGER

That split is important:

• a loop can be click-started, redstone-started, or always-running
• advance-on-trigger is for step-based puzzle devices and station selectors
• ping-pong is great for lifts, trams, and shuttle routes

Waypoint editing

The Travel menu gives you three practical path-authoring routes:

• open the waypoint list and edit entries directly
• add a waypoint at your current position
• enter Path Builder Mode and edit in the world with hotbar tools

For a short lift or shuttle, direct waypoint editing is fine. For anything large or scenic, Path Builder Mode is usually better.

Waypoint actions

Each waypoint can also own its own actions and delay.

That means a route can do something special at one exact stop or one exact corner, such as:

• play a sound
• announce a station
• fire a title
• run a console command
• run a player command

The public placeholder surface there includes:

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

That makes waypoint actions great for transport systems, cinematic rides, and roaming event props.

Walkable versus mountable

Travel becomes a real moving platform when walkable turns on. It becomes a mount-style machine when mountable also turns on.

The current public walk and mount controls include:

• walkRadiusX
• walkRadiusZ
• walkYOffset
• walkPadding
• walkHeight
• walkPlatformType
• carryMode
• carryMultiplier
• carryAffectsAir
• walkLevitationAssist
• walkUpSpeedAssist
• mountYOffset
• mountable
• mountSneakToMount

Example: walkable moving platform

travel:
  enabled: true
  trigger: ALWAYS
  mode: LOOP
  speed: 1.5
  smooth: true
  walkable: true
  walkRadiusX: 1
  walkRadiusZ: 1
  walkYOffset: 0
  walkPlatformType: COLLIDER_SHULKERS
  carryMode: SMART
  mountable: false

This is the family of settings to start from when players should stand on the machine instead of riding it as a passenger.

Example: rideable moving machine

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

Your live Duck Blocks config already shows this kind of structure clearly. This is the better starting point for cars, carts, and moving set pieces that need both standable and mountable behavior.

What the carry debug logs are telling you

Moving-platform troubleshooting gets much easier once you know the public carry-log terms:

• TOP_SURFACE
• sink
• peek
• sessionColliderCount
• FAILMOVE CLIPPED
• rescue=floor_clamp

Practical meanings:

• TOP_SURFACE usually means the player is being treated as standing on top of the structure
• sink is how much the carry system thinks the player is dropping into the platform
• peek is one of the lift or surface-adjustment helpers
• sessionColliderCount helps you see how many moving collider helpers exist
• FAILMOVE CLIPPED means the move attempted to push into a bad space
• floor_clamp means the carry system is trying to recover the player onto a stable surface

Good travel authoring order

1. Build a path with at least two clean waypoints.
2. Confirm the visual itself moves correctly.
3. Turn on walkable or mountable behavior only after the path is stable.
4. Add waypoint actions after the movement feels right.
5. Read the carry log before changing several carry settings at once.

Best next pages

• travel Paths, Walkable Platforms, and Rideable Structures
• admin Runtime, State, and Live Troubleshooting
• displays, Hitboxes, and ModelEngine