Airdrops Wiki Home

MCWAR Airdrops is Duq_'s cinematic drop plugin for scheduled crate events, manual flare call-ins, display-entity plane flyovers, parachute drops, loot container delivery, and live admin editing.

This wiki is for the people who actually run the plugin after the jar is already on a server:

• server owners bringing timed drops onto a live Paper server
• admins tuning scheduler cadence, cleanup rules, and crate interaction behavior
• content creators maintaining crate families, loot tables, models, and drop zones
• staff using the in-game GUI to edit crates without rebuilding the whole file by hand

One important version note before you start

Some of the loot content still comes from a legacy 1.15.2 MCWAR server, but the current source tree is not a 1.15.2 plugin anymore.

The current source build in this workspace is:

• MCWAR-Airdrops 2.1.35
• Paper 1.21.10+
• Java 21

That means this wiki uses the current modernized source as the truth, while still acknowledging that many crate rewards and model strings were carried forward from older server content.

What Airdrops actually covers

Airdrops is not only "spawn one chest from the sky."

It lets you run:

• weighted scheduled crate events
• manual call-ins with flare torches
• optional CrackShot flaregun support
• per-crate spawn zones
• display-model planes, parachutes, crates, and opened crate states
• container-style or world-drop loot delivery
• command, message, single-item, and weighted itemspray reward actions
• shot-down crates with impact-open behavior
• in-game admin editing, cloning, migration, and loot simulation
• orphan plane cleanup after crashes or hard restarts

Start here

If you are brand new to Airdrops, use this path:

1. Boot the plugin cleanly first
Start with install and First Boot so you validate the current Paper 1.21.x build, not an older 1.15-era assumption.

2. Lock down the server-wide runtime rules next
Read core Config and Runtime before you edit crate loot. Most live-server pain comes from interaction, scheduler, visibility, or cleanup settings, not from one reward line.

3. Learn the crate file before you touch the loot tables
Use crate Types, File Structure, and Crate Families so you know what belongs in one crate entry and what stays global.

4. Edit reward logic only after the structure is clear
Move into loot Tables, Open Actions, and Container Delivery when you are ready to tune actual drops.

5. Tune where and how crates fall
Use spawn Zones, Drop Physics, and Landing Behavior and scheduler, Call-Ins, and Smoke Plumes when the pipeline itself needs work.

6. Fix the visuals after the pipeline works
Use models, Displays, Panels, and Open Animations once the drop is already spawning and opening correctly.

7. Use the admin tooling when you want faster iteration
Read admin GUI, Migration, and Live Editing and commands, Permissions, and Admin Workflows before you start editing live servers by trial and error.

8. Keep the operations page nearby on live servers
Use cleanup, Crash Recovery, and Troubleshooting when planes get stranded, crates refuse to open, or model alignment starts drifting.

Documentation map

Getting Started

• install and First Boot
• core Config and Runtime

Crate Authoring

• crate Types, File Structure, and Crate Families
• loot Tables, Open Actions, and Container Delivery
• spawn Zones, Drop Physics, and Landing Behavior
• models, Displays, Panels, and Open Animations

Drop Pipeline and Effects

• scheduler, Call-Ins, and Smoke Plumes

Admin and Operations

• admin GUI, Migration, and Live Editing
• commands, Permissions, and Admin Workflows
• cleanup, Crash Recovery, and Troubleshooting

The file map that matters most

These are the files most admins and content maintainers actually care about:

• config.yml for scheduler cadence, crate interactions, smoke, drop physics, visuals, messages, cleanup, and admin preview defaults
• crateTypes.yml for every crate family, spawn area, model string, open rule, loot action, and named item pool
• plugin.yml for the command registration and admin permission node
• migration-reports/ for human-readable normalization and migration reports
• pending-cleanup.yml for persisted orphan-plane cleanup data after interrupted runs

Good first goals for a live server

Before you build a giant event rotation, get these right:

• one scheduled crate that announces correctly
• one crate family with clean zones
• one loot table that opens the way you expect
• one flare call-in that lands and opens cleanly
• one tested cleanup cycle after restart

When those feel solid, the rest of the plugin becomes much easier to maintain without surprises.