Launch Pads

A launch pad is a specific, registered pressure-plate block that launches whoever steps on it.

Registering one

  1. Place a pressure plate.
  2. Look directly at it (within 5 blocks) and run:
/busyhub pad create  [velocity] [height]

Requires busyhub.pad.create. If velocity/height are omitted (or fail to parse as a number), they fall back to the config defaults:

yaml 
launch-pads:
  default-velocity: 1.4
  default-height: 1.0

How the launch actually works

Triggering is stepping on the plate — Bukkit's PHYSICAL interact action, not a right-click. On trigger:

horizontal push = (direction you're facing, flattened to the XZ plane) × velocity
vertical push   = height, flat, regardless of where you're looking

In other words: it shoves you forward in whatever direction you're currently facing, at velocity blocks/tick, plus a flat vertical kick of height blocks/tick. It is not an arc toward a fixed destination — aim matters. Standing on the plate facing a wall launches you into the wall.

A pad can also run actions on trigger (/busyhub pad addaction <name> <action> / clearactions), using the same syntax as everything else — see Menus & Actions.

The tunneling risk — and why there's a ceiling on velocity

Minecraft's own collision only resolves against where you land each tick, not the path you took getting there. At high enough horizontal velocity, a single tick's displacement can carry a player cleanly through a 1-block-thick wall with no collision ever registering — the classic "tunneling" glitch. 2.0 blocks/tick horizontal is comfortably enough to do this reliably; the shipped default of 1.4 is not.

BusyHub guards against this regardless: right after a launch pad (or double jump) grants velocity, a short window opens where every subsequent move is checked with a ray trace between where the player was and where they're about to land. If a solid block sits anywhere along that path, the player is held at their last valid position and their velocity is zeroed — they hit an invisible wall instead of clipping through. This is intentionally scoped to only that brief post-boost window, not every player's every move, so it doesn't interfere with ordinary fast movement (elytra, falling) that has nothing to do with a BusyHub boost.

That guard is a safety net, not a reason to ignore the ceiling. If you raise launch-pads.default-velocity well past the default, test it against your actual level geometry — a pad that reliably slams players into the tunneling guard right next to a wall isn't a great experience even when it technically doesn't let them through.

Managing pads

/busyhub pad list
/busyhub pad remove

Pads persist in data.yml and survive restarts; /busyhub reload re-reads them from disk.