Portals
A portal is a named cuboid region that fires a list of actions the instant a player's block coordinates move into it — a config-free way to build a "walk here to be sent to server X" zone.
Creating one
/busyhub wandRequires busyhub.portal.create. Gives a blaze rod: left-click a block to set corner 1,
right-click another block to set corner 2 (both need to be in the same world). The wand
is not a wooden axe on purpose, and its clicks are claimed before other plugins see them, so
it never doubles as a WorldEdit selection. Then:
/busyhub portal create The style controls what BusyHub fills the cuboid with when it's created:
| Style | Fill |
|---|---|
water |
WATER in every air block of the cuboid |
nether |
NETHER_PORTAL in every air block of the cuboid |
empty |
Nothing — purely a logical trigger volume, no blocks touched |
Only air is filled, so you can click the two outer corners of a frame and the frame itself is left standing — existing blocks inside the selection are never replaced. The fill then stays put: water inside a portal never flows out of it, nether-portal blocks don't need an obsidian frame, and standing in them doesn't send anyone to the Nether.
Filling happens block-by-block on the region thread that owns each block (Folia-safe), so a large cuboid may take a moment to finish filling after the command returns.
Adding behavior
A freshly created portal has no actions — it's just a trigger volume until you add some:
/busyhub portal addaction
/busyhub portal clearactions See Menus & Actions for the full action syntax. A
typical portal is just one [BUNGEE] <server> action, or [WARP] <name> to send the player
to an EssentialsX warp on the same server.
Managing portals
/busyhub portal list
/busyhub portal remove Removing a portal also clears the water or nether-portal blocks it was filled with; anything else inside the region is left alone.
Portals persist in data.yml and survive restarts; /busyhub reload re-reads them from disk.
How triggering works
BusyHub tracks, per player, which portal (if any) they were last inside, and only fires actions when that changes — walking around inside the same portal's cuboid doesn't re-fire it every tick, only crossing from outside into it (or from one portal into a different one) does. This is checked against the region's block-coordinate bounds, not fine positioning, and looked up from a small per-world cache rather than scanning every registered portal on every move.