Server-Select Compass

The server-select compass is BusyHub's classic hub item: right-click it to open a config-driven menu.

Configuration

yaml

compass:
  enabled: true
  give-on-join: true
  slot: 0
  material: COMPASS
  name: "&e&lServer Selector"
  lore:
    - "&7Right-click to open"
  menu: main

Setting	Description
`enabled`	Master switch. `false` disables the right-click interaction entirely — nothing happens on right-click, for every player, no exceptions. Checked before anything else.
`give-on-join`	Whether the item is handed out automatically on join.
`slot`	Inventory slot the compass is placed in on join.
`material`	Any item material — the compass isn't identified by material, so this can be anything.
`name` / `lore`	Display name and lore. Supports MiniMessage or legacy `&` codes.
`menu`	Which file under `menus/` (by name, no `.yml`) opens on right-click.

You can also hand it out manually:

/busyhub compass give [player]

See Menus & Actions for editing what the menu actually contains.

Usage

Right-click the compass to open the configured menu. Given exactly once per join — see below.

Given exactly once, always in sync

Every time a player joins, BusyHub strips out any tagged hub compass already anywhere in their inventory (including offhand) before giving a fresh one in the configured slot. This matters because it's the only way to guarantee exactly one compass at all times: if you change compass.slot between sessions, or a player drags the compass to a different slot, a naive "just overwrite the configured slot" approach leaves the old one orphaned — the player ends up holding two. Re-scanning on every join closes that gap regardless of cause.

The item is identified by a hidden persistent-data tag, not by material, so a regular compass a player finds/crafts is never mistaken for the hub one.

It can't be dropped

Right-clicking to drop it (Q, or dragging it out of the inventory window) is cancelled — it's a fixed hub item, not something a player should be able to lose. This only applies to the compass; regular items drop normally.

Vanilla behavior is fully suppressed

Right-clicking a real compass in vanilla can bind it to a lodestone. BusyHub explicitly denies both useItemInHand and useInteractedBlock on the tagged item, so that never fires — only the menu opens. This runs at HIGHEST priority and doesn't ignore already-cancelled events, so another plugin that lets OPs bypass its own protection checks can't cause the hub compass to fall through to vanilla behavior for staff.

The GUI freezes movement — for everyone, no exceptions

Minecraft does not lock player movement while a custom inventory is open — a player can walk or fly straight through a wall, off a launch pad's edge, or through a portal's trigger cuboid while the menu covers their screen. BusyHub freezes the player's position at whatever it was the instant the menu opened, holding it there for as long as the menu stays open.

This has no permission bypass, deliberately. An earlier version exempted OPs from it to stop a rubber-banding sensation while flying with the menu open — that exemption turned out to be exactly what let an OP clip straight through walls with the menu open, because the freeze isn't cosmetic; it's the only thing stopping that.

If a player somehow ends up on the wrong side of a wall before the menu opens (see Launch Pads on tunneling), the freeze can't undo that — it only holds them wherever they already are. It's not a substitute for preventing the tunnel in the first place.

Troubleshooting

Nothing happens on right-click. Check compass.enabled — it's checked before anything else and has no per-player exception.
Menu opens but items don't send players anywhere. That's the menu/action layer, not the compass — see Menus & Actions.