Crate Types, File Structure, and Crate Families

crateTypes.yml is the real content library for Airdrops. Every drop family lives here.

What one crate entry actually contains

Each crate under crateTypes: can define:

• whether the crate is enabled
• its scheduler weight
• display name
• max active limit
• lifetime
• whether it despawns on open
• model strings
• spawn zones
• open restrictions
• open animation overrides
• open actions
• named item pools

At a minimum, the shape looks like this:

crateTypes:
  example_crate:
    enabled: true
    weight: 100
    displayName: Example Crate
    maxActive: 1
    lifetimeSeconds: 300
    despawnOnOpen: false
    models:
      planeitem: minecraft:shears{CustomModelData:176}
      crateItem: minecraft:shears{CustomModelData:155}
      parachuteItem: minecraft:shears{CustomModelData:156}
      openedCrateItem: minecraft:shears{CustomModelData:157}
      cratePanels:
        bottomItem: ''
        sideItem: ''
        topItem: ''
    spawn:
      areas: [item]
    open:
      deliveryMode: container
      commands:
        roll_each: [item]
    items: {}

The crate families already in the current source file

The current crateTypes.yml includes these live crate IDs:

• fargo_general_1
• fargo_general_2
• fargo_general_3
• medical_crate
• raider_crate_1
• raider_crate_2
• raider_crate_3
• marauder_crate_1
• marauder_crate_2
• marauder_crate_3
• imc_crate_1
• imc_crate_2
• imc_crate_3
• duck_defense_crate_1
• duck_defense_crate_2
• duck_defense_crate_3
• trade_crate
• desert_crate
• university_crate
• vehicle-oriented drops such as gray_dirt_bike_drop, jeep_drop, caravan_truck_drop, imc_plane_drop, imc_helicopter_drop, and imc_tank_drop

That is why keeping the file organized matters. This plugin is already beyond the point where one giant unstructured loot list stays manageable.

The fields most people edit first

Core scheduling identity

These decide how often the crate is chosen and how long it stays relevant:

• enabled
• weight
• maxActive
• lifetimeSeconds
• despawnOnOpen

player-side identity

These decide what players see:

• displayName
• models.*

World placement

This decides where the crate can land:

• spawn.areas

Open behavior

This decides what happens when the crate is used:

• open.deliveryMode
• open.animationMode
• open.shootDownAnimationMode
• open.permission
• open.requiredItem
• open.consumeRequiredItem
• open.deniedMessage
• open.commands.roll_each

Named item library

This gives you a local reusable item pool:

• items

That is helpful when one crate reuses several named reward items and you do not want to duplicate every serialized stack line by line.

Model fields

The crate-level models section is where each crate tells the runtime what to render:

• planeitem
• crateItem
• parachuteItem
• openedCrateItem
• cratePanels.bottomItem
• cratePanels.sideItem
• cratePanels.topItem

These per-crate values work with the global effects.plane, effects.parachute, and effects.crate settings from config.yml.

Spawn areas

Each crate can define multiple spawn zones. The current source supports at least:

• circle
• rect

Typical area fields include:

• name
• world
• shape
• centerX
• centerZ
• radius
• minX
• maxX
• minZ
• maxZ
• minY
• maxY

Keep the world and altitude bounds honest. Many bad drops are really bad zone data.

Open restrictions

Per-crate restrictions belong inside open.

The current parser supports:

• permission
• requiredItem
• consumeRequiredItem
• deniedMessage

That means one crate can be public while another requires a key item or a permission gate.

Keep legacy loot and modern runtime concerns separate

This is the biggest maintenance rule for Airdrops:

• crateTypes.yml is where the content identity and reward logic live
• config.yml is where the runtime behavior lives

Do not solve view range, physics, or cleanup problems by hacking crate reward entries. Solve those in the global config where they belong.

Next pages

Use these together:

• loot Tables, Open Actions, and Container Delivery
• spawn Zones, Drop Physics, and Landing Behavior
• models, Displays, Panels, and Open Animations