Skip to main content
Block Arsenal

Wiki

Airdrops wiki

Wiki

Airdrops Wiki

Scheduled drops, flare call-ins, loot crates, admin tooling, and crash-safe cleanup for MCWAR Airdrops.

Getting Started

Start here for the current Paper build, first boot checks, and the runtime settings that affect every drop.

Wiki HomeInstall and First BootCore Config and Runtime

Crate Authoring

Learn how crate families are structured, where the loot really lives, and how zones and models fit into one crate definition.

Crate Types, File Structure, and Crate FamiliesLoot Tables, Open Actions, and Container DeliverySpawn Zones, Drop Physics, and Landing BehaviorModels, Displays, Panels, and Open Animations

Drop Pipeline and Effects

Run the scheduled event lane, manual call-ins, and the staged smoke signaling that tells players where to look.

Scheduler, Call-Ins, and Smoke Plumes

Admin and Operations

Use the in-game tools, command surface, migration support, and cleanup systems that make the plugin maintainable on live servers.

Admin GUI, Migration, and Live EditingCommands, Permissions, and Admin WorkflowsCleanup, Crash Recovery, and Troubleshooting
Why cleanup exists at allThe cleanup system`pending-cleanup.yml`Common real-world problems"The crate is there, but players cannot open it""The drop is happening, but nobody can see it from far enough away""The model looks buried or sideways""The scheduler feels wrong""Manual call-ins do nothing""Planes are lingering after restart"Debug stepsGood ops habitsNext pages
Admin and Operations

Cleanup, Crash Recovery, and Troubleshooting

Handle orphan planes, restart cleanup, click problems, visibility issues, and the most common live-server failure points.

Plugin downloadsAirdrops

This is the page to keep nearby on a live server.

Why cleanup exists at all

Airdrops uses long-travel display logic for planes, parachutes, and crates. If the server is hard-killed while a plane is active, you can end up with leftover entities saved to disk.

The current plugin has explicit cleanup logic to deal with that.

The cleanup system

The main cleanup controls live under cleanup in config.yml.

Important keys:

  • enabled
  • cleanOnChunkLoad
  • recordFlightPath
  • startupSweep.enabled
  • startupSweep.chunksPerTick
  • targets

The current default target list is plane-focused:

YAML
targets: ["plane"]

That is deliberate. The most common orphaned entity problem in this plugin is the plane lane.

pending-cleanup.yml

When recordFlightPath is enabled, the plugin writes the plane's chunk path so it can clean the leftover entity later even if the server did not shut down cleanly.

If you see that file after a forced restart, that is usually normal.

Common real-world problems

"The crate is there, but players cannot open it"

Check:

  • interactions.crate.blockClickRadius
  • interactions.crate.ignoreInteractableBlocks
  • whether foliage or a nearby interactable block is stealing the click
  • whether the crate has an open.permission or open.requiredItem restriction

"The drop is happening, but nobody can see it from far enough away"

Check:

  • effects.viewRange.default
  • effects.plane.viewRange
  • effects.parachute.viewRange
  • effects.crate.viewRange
  • player render distance and server tracking expectations

"The model looks buried or sideways"

Check:

  • effects.crate.baseYOffset
  • effects.crate.displayScale
  • effects.crate.displayTransform
  • effects.parachute.basePitchDegrees
  • effects.parachute.baseRollDegrees
  • effects.parachute.xOffset
  • effects.parachute.zOffset

This is especially common when the content came from an older 1.15.2 resource-pack workflow.

"The scheduler feels wrong"

Check:

  • scheduler.enabled
  • scheduler.baseIntervalMinutes
  • scheduler.randomJitterMinutes
  • scheduler.announceOffsetsSeconds
  • general.onlyOneActiveDrop

"Manual call-ins do nothing"

Check:

  • callins.enabled
  • callins.torch.enabled
  • whether the call-in service actually initialized
  • whether the target crate ID exists

"Planes are lingering after restart"

Check:

  • cleanup.enabled
  • cleanup.cleanOnChunkLoad
  • cleanup.recordFlightPath
  • cleanup.startupSweep.enabled

Then make sure the server actually loaded the relevant chunks after restart.

Debug steps

The safest quick diagnostic loop is:

  1. /airdrop debug on
  2. reproduce one exact case
  3. inspect the result and config
  4. /airdrop debug off

Use /airdrop status before and after the test so you know whether the problem is scheduler state, active-drop state, or crate content.

Good ops habits

  • keep backups before large crate-table edits
  • run migration after major legacy merges
  • test one call-in and one scheduled drop after config changes
  • keep cleanup enabled on servers where forced restarts can happen

Next pages

PreviousCommands, Permissions, and Admin Workflows