CloudMeteorite — the "Meteorite" event

The sky cracks, a glow flares at the horizon — and a red-hot ball crashes to the ground with a roar: coal, magma, debris from the lower world. A moment later fireballs rain down from above, and at the foot of the meteorite four chests wait, locked until the deadline. CloudMeteorite turns a random point on the map into a place worth risking — and it's not a stage show but what actually happens on the server while the timer ticks down to the unlock.

What it is

CloudMeteorite is an event plugin for Paper 1.19.4, positioned as an add-on to the Cloud Ultra Anarchy+ line and its signature Lovecraftian theme: the meteorite is presented not as decoration but as a fragment of something ancient that fell from the sky onto the server. The plugin itself raises a ball of coal and magma at a random point on the map, launches a fire rain around it, locks the loot in four chests until the timer runs out — and then cleans up after itself, restoring the terrain as it was, down to the last block.

For a server it's a ready-made reason to gather players at one point: a short, loud event with a clear goal — get there, survive the rain, and manage to open a chest. No manual reward handout, no manual terrain restoration, no watching the timer — all on schedule, automatic, and it repeats by itself. Next, phase by phase, with numbers from the config.

How the event plays out

The fall and building the ball

The plugin usually picks the impact site itself — a random point within a radius (200 blocks by default) of a given map center, always on the surface: the height is taken from the topmost block at that point. Or an administrator sets exact coordinates with a command. Before building, the plugin takes a snapshot of the whole 9×9×9 cube — 729 blocks (2×radius+1 at a ball radius of 4) — around the center, in order to later restore the terrain one-to-one, block by block, along with its orientation.

Then comes the build itself. Inside a sphere of radius 4 blocks, for each position: in roughly 20% of cases the block isn't touched at all (whatever was there shows through the meteorite — grass, stone, air), of the rest about 5% turn into lava pockets, and everything else becomes the shell: coal and magma half and half near the surface, and deeper, in the "core", a mix of coal, magma, and netherrack. The result isn't a smooth ball but a charred, damaged-looking chunk with signs of impact. If WorldEdit is installed on the server and a schematic file is specified in the config, a ready-made template is pasted instead of generating (a separate setting decides whether to overwrite existing terrain with air); with no file or plugin, CloudMeteorite quietly builds the meteorite itself, with no errors and no stopping of the event.

Right there, 7 blocks from the center (ball radius + 3) at the four cardinal directions, 4 chests appear — each at the height of its own point, not necessarily level with the meteorite itself. The loot is placed in them right away, at build time rather than at unlock time: the chest is already full, zone protection just doesn't let you open it early.

Impact: sound, flash, title, and boss bar

At the moment of impact a whole bundle of effects fires at once. The explosion sound (generic explode by default) at volume 1.5 and pitch 0.8 plays for every player in the meteorite's world — and it plays "at the listener", so it's heard equally loudly by everyone in that world, not only by those near the impact. At the impact site, 5 large explosion particles flash and 40 lava particles scatter — and that part is visible only to those physically close, within normal particle render distance.

The on-screen title is worth checking against the code separately, because the setting's name is misleading. In the config it's labeled "title for players in the zone", and the internal method in the code is called "for nearby players" — but in fact "☄ METEORITE!" with the hint "Run to the center — there are chests with loot!" goes to every player in the meteorite's world, with no distance check at all (0.5 seconds fade-in, 3 seconds on screen, 1 second fade-out). The countdown boss bar behaves the same way — it's attached to everyone in the world and every second picks up those who joined or moved into that world after the start. And chat messages about the start, unlock, and finish are a broadcast to the entire server, all worlds at once, not only the world where the meteorite fell.

A nuance: after the unlock, the boss bar and hologram don't switch to a separate "opened" view on their own — the boss bar keeps showing "0s", and the hologram briefly shows the unlocked text and is immediately overwritten back by the same countdown, frozen at zero. The real status at that moment is more reliably checked via /meteorite info or the unlock chat message.

The fire rain

The rain starts simultaneously with the impact: over a 20×20 block area around the meteorite, from a height of 30–50 blocks above the terrain, fireballs spawn one after another — a new one every 30 ticks, i.e. roughly once every second and a half — and fall almost straight down with barely noticeable random drift. They don't touch blocks: they don't set fires or dig craters — this is suppressed at the entity level, and the explosion is additionally cleaned up by claim protection. All damage goes only to living entities within 3 blocks of the impact point, and not only players: a zombie or someone's cow caught nearby takes the same 4.0 damage — that's 2 hearts, going by the config's convention where 1.0 = half a heart. A player with the meteorite.bypass permission is fully protected from this damage.

On each fall there is an independent 5% chance to knock out a bonus item right on the spot (table below). Over the standard 15 minutes of rain about 600 fireballs accumulate — so on average roughly 30 bonus drops per event are expected, even before anyone touches a chest. While a fireball is in flight, a trail of flame and smoke particles follows it; this can be turned off in the config.

Zone and protection

From the moment of impact until cleanup, a claim region is in effect around the meteorite — and although in the config it's labeled a "cube", in fact it's not quite a cube. With the default setting (region.size: 10) the region extends 5 blocks from the center in each horizontal direction — 11×11 blocks in plan — but upward it goes noticeably further: not 5 but 5 + the ball radius (4) + 2 blocks of margin, i.e. 11 blocks up from the center at standard settings (17 blocks of height in total) — meant to cover both the ball itself and the hologram above it with room to spare. Downward the region goes only the same 5 blocks.

Inside this volume, players without meteorite.bypass are forbidden practically everything: they can't break or place blocks, can't interact with any block at all — not only chests but any door, button, or furnace; chorus fruit and ender pearl teleports don't work, and chests can't be opened before the unlock. An explosion inside the region — whether from the plugin's own fireballs, a stray creeper, or someone's TNT — doesn't damage blocks, although entities can still take damage. The meteorite.bypass permission lifts all these restrictions at once, including the chest lock: with it you can look inside even before the official unlock.

Timing

The full cycle of one event is a fixed sequence of phases:

• T+0 — impact, ball build, 4 loot chests, rain starts, boss bar and title
• T+15 min (default, chest.open-after-minutes) — the rain stops, chests are unlocked, chat is notified
• T+20 min (another cleanup.after-unlock-minutes = 5) — the structure and chests disappear, the region is lifted, the terrain is restored
• Every 120 min (default, event.interval-minutes) — the auto timer tries to start a new event on its own

The config has a separate fireball.duration-minutes parameter with the comment "matches the chest opening timer" — but the code never reads it: the real rain duration is fully determined by chest.open-after-minutes, and that's the one to change. The auto timer itself is simple: it ticks on a fixed schedule from the moment the server starts, not recalculating the interval from the end of the previous event, and if at the next tick an event is somehow still active, it just skips the attempt and comes back on the next one.

Loot and rewards

Each of the four chests holds a random set from the shared loot table: 12 of 27 cells are filled (the number is configurable), positions inside the chest are shuffled randomly, and the items themselves are chosen independently of each other — so the same item can easily drop twice in one chest. Weight determines how often an entry drops relative to the others; the "Chance" column below is the share of the table's total weight (115).

The fireballs have their own, more compact table (total weight 73), and it triggers only on that same 5% drop chance on each fall:

Both tables accept not only items but also "command" entries: instead of a material you specify a console command with the %player% placeholder — for example, to hand out something from another reward system on the server. In the chest loot table this really works: the command fires once — for whoever first opens that particular chest, so at most 4 triggers per event, one per chest, not one per player. In the fireball table a command entry is pointless and is always silently skipped: a falling fireball has nobody to substitute into %player%. The base config has no active command entries — only commented-out examples to get you started, and out of the box both loot sources give out items exclusively.

Integrations

CloudMeteorite relies on two third-party plugins but doesn't require either — both are "soft" dependencies. If WorldEdit is found, you can prepare your own meteorite schematic and paste it instead of procedural generation, getting a unique chunk shape for your server. If DecentHolograms is found, a hologram with the text from the config hangs above the meteorite, with separate line templates for "locked" and "open" using the %time% placeholder. If neither is found, CloudMeteorite quietly switches to built-in means and writes to the log at startup what exactly it found, and the event runs as usual, without a single error in the console.

Commands

All management goes through a single command, /meteorite (the Russian alias /метеорит also works), available only to those with meteorite.admin.

There is a subtlety with coordinates: both numbers, x and z, are needed at once. If they don't parse as numbers, the command refuses explicitly with a syntax hint; and if only one number is given instead of two, the command silently falls back to a random spot, as if no coordinates had been given at all. Trying to start an already active event or stop an inactive one returns a clear error in chat rather than silence.

There is a less obvious point with reload: the command always reports success in chat, and the raw values from config.yml really are reloaded immediately. But both loot tables and the auto timer are refreshed from the cache only if no event is active at the time of the reload — it's better to make loot edits and reload between events, not during them.

stop and natural completion are not the same for players, although the outcome is identical. On normal completion, chat gets a message that the structure dissolved on its own; on early stop, a separate message that an administrator stopped it. The cleanup itself — chests, structure, region, boss bar, hologram — is the same and complete in both cases.

Permissions

• meteorite.admin — access to all /meteorite subcommands (operators by default)
• meteorite.bypass — full immunity to the event zone: ignores claim protection (break, place, interact, teleport), takes no damage from the fire rain, and opens chests at any time, even before the official unlock (operators by default)

How to run it and keep the atmosphere

The impact site should be kept in an already developed, accessible part of the map: too far out and nobody will make it in 15 minutes, while too close to spawn or someone's build and for 20 minutes someone gets a region in their yard with a full ban on interaction. That's what spawn.center-x/z and spawn.radius are for — the scatter can be kept strictly within a long-settled zone, without touching the frontier.

Since the title, boss bar, and chat notification hit the whole world regardless of distance, this is a ready tool for gathering even a widely scattered anarchy server at one point: it's physically impossible to miss the announcement, wherever the player is building at the moment. The Lovecraftian presentation of the Cloud Ultra Anarchy+ line — a fragment of something ancient that fell from the sky, not a textbook meteor — fits naturally: the mechanic itself imposes nothing, but your own chat announcements or signs at spawn can be written to match this theme.

120 minutes by default is a rhythm worth checking against actual attendance: on a quiet server the event risks becoming a forgotten one-off, on a busy one — a rain that never quite ends. And since everything cleans up by itself, keeping the event on auto-start is more reliable than launching it by hand every time.

Configuration

The config is fully open and grouped by meaning:

• Auto timer — event.auto-enabled, event.interval-minutes
• Impact zone — spawn.world, spawn.center-x/z, spawn.radius
• Structure — structure.radius (ball size) and schematic.file / schematic.paste-air — an alternative in the form of a ready-made schematic
• Protection region — region.size
• Chests — chest.open-after-minutes, loot-slots
• Both loot tables — loot and fireball.drop-loot, line by line: material (or command), weight, minimum and maximum quantity
• Fire rain — fireball.zone-size, damage, radius, spawn-interval-ticks, item-drop-chance
• Cleanup — cleanup.after-unlock-minutes
• Effects — the boss bar and its color, a hologram with separate lines for "locked" and "open", the fireball trail, the impact flash with sound, a title with its own text and subtitle

After editing, run /meteorite reload. As noted above, raw values are picked up immediately, but loot tables and the auto timer only if no event is active at that moment.

CloudMeteorite is not a picture for five seconds but a complete cycle: spawn, risk, reward, cleanup, and quiet again until next time. Set the numbers to your server's rhythm once — and from then on the meteorite falls by itself, on schedule, hits the whole world with an announcement, and leaves behind not a single broken block.