Commands & Permissions

The Pit registers its commands at runtime, and their permission model is a design statement: player commands have no permission nodes — they are gated by levels instead, exactly like the game that inspired the genre. Only the admin and setup surface uses permission nodes (thepit.setup, thepit.economy, thepit.build, thepit.reset, or the wildcard thepit.*), all defaulting to op. The full surface splits into three tables.

#Setup commands

All setup subcommands require thepit.setup (or thepit.*) and only load while setup mode is active. They place the world's features — run them in the order the in-game helper suggests, or drive the whole flow from /thepit gui.

#Admin subcommands

Eight admin subcommands cover economy edits, building and the reset hammer. Each carries its own node, all defaulting to op — grant them by node, not by wildcard, where you can.

#Player commands — level gates, not permissions

Ten standalone player commands cover the day-to-day game. None of them checks a permission node — each unlocks at a level, mirroring the original Pit's design where progression *is* the permission. The unlock table is also the reference for your holograms' feature list.

#Why level gates instead of permissions

Two practical reasons, both honest. First, design faithfulness: the Pit experience is built around unlock levels — chat at 5, perks at 10, enderchest at 15, contracts at 30, stats at 50, trade at 60, view at 70, prestige at 120 — and a permission mirror of that would be eleven more nodes to misconfigure for zero benefit. Second, operations: player commands need no permission plugin wiring at all, so a fresh Pit server works on any permissions setup (or none). Admin power stays exactly where it belongs — in the thepit.* nodes above, all defaulting to op.