Scheduler, Call-Ins, and Smoke Plumes

Airdrops has two major event lanes:

• the scheduled drop pipeline
• manual call-ins

Treat them as related systems, not the same system.

Scheduler basics

The recurring event loop lives under scheduler in config.yml.

Key controls:

• enabled
• baseIntervalMinutes
• randomJitterMinutes
• announceOffsetsSeconds
• autoReschedule

This is the part of the plugin that makes drops feel like a world event rather than an admin-only toy.

Announcement timing

announceOffsetsSeconds should stay intentional and readable.

The current config ships with a long descending schedule:

[3600, 1800, 900, 600, 300, 60, 30, 10, 5]

If your server does not need a one-hour warning window, shorten it. A long countdown is only good if the server design actually uses that anticipation.

Manual call-ins

The manual lane lives under callins.

This is where you control:

• whether call-ins are enabled at all
• whether they can ignore general.onlyOneActiveDrop
• whether the smoke cloud is enabled
• flare torch behavior
• optional CrackShot flaregun behavior

Flare torch workflow

The main manual admin item is:

/airdrop givetorch <crateType> [player] [amount]

The torch lane is useful when you want:

• event staff to trigger one exact crate family
• map-based objectives that summon a reward drop
• testing of one crate family without touching the scheduler

CrackShot flaregun bridge

The plugin can also listen for a CrackShot weapon hit and turn that into a weighted random drop call-in.

That bridge lives under:

callins:
  crackshot:
    enabled: false
    weaponTitle: "flaregun"

If you enable it, test it thoroughly. Projectile-triggered workflows can feel clean or chaotic depending on how your wider combat stack is built.

Smoke plume staging

The smoke plume is not a cosmetic afterthought. It is the target signal players read before the drop arrives.

The current config supports:

• staged progress windows
• spread growth
• dust-color interpolation
• an optional neutral smoke overlay

The current source explicitly preserves the older MCWAR warning plume progression:

• green
• yellow
• orange
• red

That is a good example of legacy content surviving inside a newer runtime cleanly.

How call-ins and scheduler limits interact

The most important policy switch is:

callins:
  ignoreOnlyOneActiveDrop: true

If this is true, flare-based call-ins can bypass the normal single-drop rule. That may be perfect for staff event control, or it may be too loose for a tightly paced server.

Good event-pipeline testing order

1. test one scheduled drop
2. test the scheduler cancel and reschedule flow
3. test one flare torch call-in
4. test one CrackShot call-in only if that integration is active
5. confirm smoke, drop, open, and cleanup all complete in one full cycle

Next pages

• core Config and Runtime
• commands, Permissions, and Admin Workflows