Every eight hours (the default, and the interval is configurable), a chest appears inside a pyramid. The server feels it: everyone drops what they're doing and runs to one point on the map, because the prize goes to whoever gets there first. There's no complicated mechanic for the player: you see the flash, hear the Wither roar and the chat announcement, run through a line of invulnerable guards, and open it. The plugin handles everything else: the timer, the pyramid schematic, the protected region, guard spawning, and weighted loot. Everything is broken down in detail below, down to the exact numbers from the code.
CloudTombEvent is the "Tomb" event for Paper 1.19.4 (Java 17, api-version 1.19) from the Cloud Delight studio. The idea is honest, with no extra layers: in the middle of the world stands a pyramid, inside it is a protected region with invulnerable husk guards, and deep within, on a timer, a chest with a reward appears. The atmosphere is built on details: a humming beam above the chest, a ring of fire particles, the Wither's roar when the loot appears, a flash, and server-wide chat that announces the winner's name to everyone.
The plugin is fully self-sufficient: basic operation needs no third-party plugin. The region, timer, guard spawning, loot, and effects work out of the box. Three integrations (WorldEdit, bAirDrop, DecentHolograms) are connected as soft dependencies and only extend what's possible, without breaking the event when they're missing. Control is a single /tomb command with five subcommands (the alias /гробница works too), and permissions are OP-only by default.
The plugin does not build the pyramid itself. It's either a ready-made structure on the map or a WorldEdit schematic that the /tomb paste command pastes in. The process: build the pyramid once by hand, select it with //wand, save it with //schem save name, copy the resulting .schem file into plugins/CloudTombEvent/schematics/, and put the file name in schematic.file. The command reads the file through the WorldEdit API (the format is detected automatically from the extension), opens an EditSession, and pastes the buffer at the schematic.paste-x/y/z point, the same origin corner that was used when selecting the original. The paste-air: false parameter is the default, so the schematic's air is ignored on paste instead of gouging a rectangular pit in the terrain. Set it to true and you get a full overwrite of the volume, including empty space. If WorldEdit isn't on the server, the command simply refuses, and a hand-built pyramid works as if nothing happened: the schematic is entirely optional.
The pyramid.center-x/y/z field in the config is purely informational: the code never reads it anywhere, in any command or mechanic. It's just a note for the tech admin about where the pyramid's center is. The working value is region: a rectangular bounding box defined by min-x/y/z and max-x/y/z, which is both the claim zone and the guard spawn zone. The box is always a rectangular cuboid, so if the pyramid is stepped, the protected zone is still rectangular and may include empty space outside the visible walls.
Inside the region stand husks (Husk) with the custom name "Tomb Guardian" (the text and color are configurable, and the name is always visible above the head). The guard differs from an ordinary husk in three ways. First, the invulnerable flag, set directly through the API: no damage at all, from weapons, falls, or sunlight. Second, health: on top of the husk's standard 20 HP (10 hearts), the config adds husks.bonus-hp (40 by default), for a total of 60 HP, 30 hearts. Third, speed: the speed-multiplier multiplier (1.2 by default) gives +20% to base movement speed.
Spawning runs on a timer: every husks.spawn-interval-ticks ticks (100 = 5 seconds by default) the plugin tries to add another guard at a random point in the bounding box, but only if a player is actually standing within 64 blocks of it. Otherwise the tick is skipped, so mobs aren't spawned in empty chunks. The cap on simultaneous guards (max-husks, 10 by default) is counted not by an internal counter but by directly counting real entities in the world carrying the plugin's tag, the PersistentDataContainer key tomb_husk. A counter would lie when chunks unload, and a tag doesn't.
A correction to a common assumption: the guards are not immortal in the sense of "eternal". Damage doesn't affect them, but standard vanilla despawn logic still happens after players are away for a long time (setRemoveWhenFarAway(true)). The code marks this as a deliberate fix: the flag used to be false, and guards piled up forever, turning into an entity leak and extra load. For the same reason, when the plugin stops (restart, /tomb reload), all tagged guards are forcibly removed, so no junk is left between restarts.
The interval is chest-respawn-hours, 8 by default. These are real-time hours, not in-game days: the plugin converts them to ticks using the formula "one hour = 72000 ticks" (20 ticks per second × 3600 seconds) and schedules a delayed scheduler task. The countdown starts when the server starts, and again right after the previous chest is opened.
Spawning is either the built-in mechanism (the default) or a hook into bAirDrop. Built-in: a CHEST block is placed at the chest.x/y/z coordinates and filled with loot from the table. Hook: if use-bairdrop: true and bAirDrop is actually installed, the console command from bairdrop-command runs instead, with {x}/{y}/{z} substituted, and from there bAirDrop decides the drop's fate while the Tomb plugin stays out of it. If the command in the config is empty, the plugin notices, writes a warning to the log, and still places a regular chest so the event doesn't fail.
Opening is caught by an inventory listener: the system checks that the opened Chest stands at exactly the same coordinates and in the same world as the active event chest, so a neighboring chest doesn't trigger the event. Once it fires, the chest is removed from tracking, the announcement goes out not just to the pyramid's world but to the entire server, and the next cycle is scheduled that same second.
A practical detail: /tomb reload is not just "apply the new numbers". If no chest is standing at that moment (a countdown is running), reload resets the current countdown and starts the full chest-respawn-hours over again instead of continuing from where it was interrupted. If a chest is already active and waiting to be opened, reload doesn't touch it at all, and the timer and position stay as they are.
The moment of appearance is the loudest: a sound of your choice (effects.spawn-sound, ENTITY_WITHER_SPAWN by default, the Wither's roar) is heard by all players in the pyramid's world, plus FLASH and EXPLOSION_HUGE particles right above the chest. After that, while the chest waits: a rotating ring of particles (effects.particle, FLAME by default) made of 24 points with a 1.2-block radius around the base, rotating every 4 ticks, and, if effects.beam is enabled, a solid vertical END_ROD column 25 blocks tall, visible from afar like a beacon. When it's opened, the ring and beam go out, replaced by a burst of 40 TOTEM particles (the same ones you see when respawning with a Totem of Undying) and a separate closing sound (effects.open-sound, beacon deactivate by default).
If DecentHolograms is installed, a hologram with two states hangs 1.6 blocks above the chest: while waiting, a countdown with the %time% placeholder (updated once a second, in "Hh Mm Ss" format); when the chest appears, a call to open it. The text of both lines is configurable. Without DecentHolograms, the event runs the same way, just without the floating sign and without errors in the console.
An honest note on the level of detail: whether each effect is on, the particle and sound type, and the hologram text are all in the config. But the number of particles in the ring, the radius, the update frequency, the beam height, the number of totem particles, and the hologram offset are constants in the code and aren't exposed in the config. One more nuance: after /tomb setchest the hologram doesn't move to the new spot by itself. Its position updates only when it's recreated (/tomb reload while the chest is inactive, or a server restart). Otherwise the sign hangs over the old point for a while, while the chest appears at the new one.
The table is weighted: the higher the weight, the more often the item drops. By default the plugin fills 9 random slots of the chest's 27 (loot-slots), and the rest stay empty. Positions within the grid are shuffled every time, so the loot doesn't sit in a clump in one row. Each of the 9 slots is an independent roll over the whole table, so the same item can drop several times in one chest. The default total weight is 119, which gives the percentages:
| Item | Weight | Chance per roll | Amount |
|---|---|---|---|
| Iron ingot | 30 | 25.2% | 3–16 |
| Bottle o' Enchanting | 25 | 21.0% | 4–16 |
| Gold ingot | 20 | 16.8% | 2–8 |
| Emerald | 15 | 12.6% | 1–5 |
| Diamond | 10 | 8.4% | 1–3 |
| Golden apple | 8 | 6.7% | 1–2 |
| Diamond sword | 5 | 4.2% | 1 |
| Diamond chestplate | 4 | 3.4% | 1 |
| Enchanted golden apple | 2 | 1.7% | 1 |
The whole table is changeable in the config. The material is taken by name from the Bukkit Material, each row has its own weight and amount range, and there can be as many rows as you like. If you misspell a material name, the plugin won't crash: it just skips the row and writes a warning to the log on load.
Inside the bounding box a strict claim applies to everyone except players with tomb.bypass (OP by default). Forbidden: breaking blocks, placing blocks, clicking on anything (doors, levers, buttons, any block with an interface), and also scooping and emptying buckets. Each violation is answered with a claim message in chat to the offender.
tomb.bypass removes all restrictions at once. Usually only the tech admin has this permission, to maintain the pyramid.The basic installation is the same for any scenario: put the jar in plugins/, restart the server (a config.yml with placeholders is created), enter real coordinates for your map, and run /tomb reload, which works without a restart.
Nothing extra: enter region.min/max and chest.x/y/z (the fastest way is to stand on the right block and run /tomb setchest) and leave the schematic.file field empty. The claim and guard spawning work right away from the region, and no schematic is needed at all.
Handy when you need the pyramid to be identical on several maps or want to rebuild it after terrain damage: build the reference once, save the .schem, put it in schematics/, set the file and paste point, and /tomb paste places a copy with one command. Want to move the pyramid? Change paste-x/y/z and paste again.
If bAirDrop is already installed on the server and you want the "Tomb" to look like the other airdrops, enable use-bairdrop: true and set the command. If you don't have bAirDrop or don't need it, there's nothing to enable: the built-in chest with the loot table from this same config works.
The hologram is optional. Without DecentHolograms, the event runs without a floating timer above the chest: players learn about the chest appearing from the sound, the particles, and the chat announcement, and you can check the status at any time with /tomb info.
So you don't have to wait the real 8 hours, /tomb spawn places the chest immediately, bypassing the timer, and you can see the loot and effects right away. /tomb info shows whether the chest is active, how many guards are alive out of the cap, and a summary of the region.
All subcommands require tomb.admin (OP by default), and the alias /гробница works instead of /tomb:
| Command | What it does |
|---|---|
/tomb reload | Re-reads config.yml. If a chest is waiting to be opened, it doesn't touch it; if there's no chest, it resets the countdown and starts the interval over |
/tomb spawn | Force-spawns the chest right now, bypassing the timer, for testing loot and effects |
/tomb paste | Pastes the pyramid schematic from schematics/ (needs WorldEdit and a filled-in schematic.file) |
/tomb setchest | Saves the chest coordinate from the player's current position; the hologram moves to the spot only after /tomb reload |
/tomb info | Status: whether the chest is active and where, time until the next one, living guards out of the cap, a region summary |
| Permission | Default | What it gives |
|---|---|---|
tomb.admin | OP | Access to all /tomb subcommands |
tomb.bypass | OP | Full bypass of the region claim: break, place, and interact without restrictions |
Both permissions are OP-only by default. An ordinary player anywhere in the pyramid's perimeter can only open the event chest itself once it appears, and nothing more.
The full list of what the plugin reads from config.yml (except the license block, which is about leak protection, not the event):
| Parameter | Default | What it does |
|---|---|---|
world | world | The world where the pyramid stands |
pyramid.center-x/y/z | 0 64 0 | An informational center point, never read by the code |
region.min/max-x/y/z | -10 60 -10 / 10 80 10 | Bounding box: the claim and the guard spawn zone |
chest.x/y/z | 0 65 0 | The chest coordinate; easiest is /tomb setchest |
chest-respawn-hours | 8 | The interval for a new chest, in real-time hours |
open-broadcast | text with & and {player} | A message to the whole server when the chest is opened |
use-bairdrop / bairdrop-command | false / "bairdrop spawn {x} {y} {z}" | A hook into bAirDrop instead of the built-in chest |
loot | 9 entries | The loot table: material/weight/min/max |
loot-slots | 9 | How many of the 27 slots to fill |
husks.enabled | true | Enables periodic guard spawning |
husks.spawn-interval-ticks | 100 | How often to try to add a guard (5 sec) |
husks.max-husks | 10 | The cap on guards alive at once |
husks.custom-name | &4Tomb Guardian | The name above the guard's head |
husks.bonus-hp / speed-multiplier | 40.0 / 1.2 | The HP addition (60 total) and the speed multiplier |
schematic.file | empty | The .schem name in schematics/; empty means unused |
schematic.paste-x/y/z / paste-air | 0 64 0 / false | The paste point and whether to paste the schematic's air |
effects.hologram | true | Show the hologram (needs DecentHolograms) |
effects.hologram-lines / hologram-idle | 2 lines each | The hologram text: chest active / countdown running (%time%) |
effects.particles / particle | true / FLAME | The particle ring around the chest and its type |
effects.beam | true | A vertical END_ROD beam above the chest |
effects.spawn-sound / open-sound | WITHER_SPAWN / BEACON_DEACTIVATE | Sounds for the chest appearing and being opened |
Any change is picked up with the /tomb reload command without a server restart, except for the hologram position nuance covered above.
The "Tomb" is not map decoration but a working cycle: an exact timer, honest weighted loot, a protected region, and an invulnerable, but not eternal, guard. The core is built and tested down to small details like the rotation of the particle ring. The tech admin only needs to enter the coordinates of their pyramid and start the countdown.