Starter Templates for Guns, Throwables, Consumables, Grapples, and Devices

Duck Shot's editor templates are the cleanest way to start a new item without dragging old baggage into the file.

The important idea is simple:

• start from the template that already matches the item family
• get one working item first
• add only the systems that actually belong on that item

That approach keeps your pack readable and makes later tuning much easier.

Which template should you start from?

Use this quick rule:

• gun_base.yml for firearms
• throwable_base.yml for grenades, shells, simple planted charges, and throwable explosives
• consumable_base.yml for med kits and one-use support items
• grapple_base.yml for traversal tools, recovery tools, and hook-style utility items
• plantable_mountable_base.yml for mounted devices, plantable launchers, mortars, and sky-select hardware

If an item feels hard to organize, the usual problem is that it started from the wrong template.

gun_base.yml

This is the right starting point for most rifles, SMGs, pistols, LMGs, DMRs, and shotguns.

id: NEW_GUN
enabled: true
category: RIFLE
tier: COMMON
classifications:
  - primary
  - rifle
 
display:
  name: '<green>New Gun'
  material: SHEARS
  custom_model_data: 1
 
ammo:
  type: RIFLE
  magazine_size: 30
 
reload:
  ammo_consumption_mode: INHERIT
  duration_ticks: 40
 
fire:
  mode: SEMI
  shots_per_second: 4.0
  projectiles_per_shot: 1
 
projectile:
  type: ARROW
  speed: 10.0
  gravity: false
 
damage:
  base: 5.0

Why this template works:

• it already has the normal firearm identity blocks
• it already has ammo, reload, fire, projectile, and damage in the right order
• it stays small enough that you can tell what changed

Best first edits:

• set the correct classifications
• tune ammo.type and magazine_size
• decide whether the weapon is SEMI, BURST, or AUTO
• add aim, recoil, sounds, and particles_v2 only after the weapon fires correctly

Go deeper here:

• weapon File Structure
• fire, Recoil, and Aim
• ammo Families, Variants, and Custom Rounds

throwable_base.yml

This is the clean starter for grenades, explosive shells, and simple throwable devices.

id: NEW_THROWABLE
enabled: true
category: EXPLOSIVE
tier: COMMON
classifications:
  - throwable
  - explosive
 
visual_key: grenade
 
display:
  name: '<green>New Throwable'
  material: SHEARS
  custom_model_data: 1
 
throwable:
  enabled: true
  fuse_ticks: 60
 
projectile:
  type: ITEM
  speed: 1.0
  gravity: true
 
explosion:
  enabled: true
  power: 2.0
  break_blocks: false

Why this template works:

• it starts from a thrown item instead of pretending the item is a rifle
• it already uses a throwable block and an explosive branch
• it keeps the default world damage conservative

Best first edits:

• set the fuse_ticks
• decide whether the projectile should bounce, stick, plant, or explode on impact
• tune break_blocks and any block-breaking rules carefully before going live
• add sound stages and particle stages after the gameplay loop works

Go deeper here:

• throwables, Explosives, and Flashbangs
• explosive Payloads, Clusters, and Strike Recipes
• block Breaking, Restoration, and Craters

consumable_base.yml

This is the starter for bandages, med kits, and other use-once support items.

id: NEW_CONSUMABLE
enabled: true
category: CONSUMABLE
tier: COMMON
classifications:
  - consumable
 
visual_key: medkit
 
display:
  name: '<green>New Consumable'
  material: PAPER
  custom_model_data: 1
 
consumable:
  enabled: true
  heal_hearts: 2.0
  use_duration_ticks: 20

Why this template works:

• it avoids firearm-only branches that would just add noise
• it already frames the item as a support tool
• it is small enough to expand into healing, buffs, or special-use items later

Best first edits:

• decide whether the item heals, buffs, cleanses, or triggers a utility effect
• set a classification that fits the slot and category behavior you want
• add simple feedback first, then move into staged sounds or particles

Go deeper here:

• input Binds, Consumables, and Alt Actions
• loadouts, Support Items, and Classification Design

grapple_base.yml

This is the dedicated base for movement tools and pull-based utility items.

id: NEW_GRAPPLE
enabled: true
category: CONSUMABLE
tier: COMMON
classifications:
  - support_item
  - tool
  - grapple
 
visual_key: grapple_default
 
ammo:
  type: DEV
  magazine_size: 5
 
fire:
  mode: SEMI
  shots_per_second: 4.0
 
projectile:
  type: ARROW
  speed: 1.0
  gravity: false
 
grapple:
  enabled: true
  range_blocks: 56.0
  cooldown_ticks: 8
  allow_blocks: true
  allow_items: true
  allow_mobs: true
  allow_players: false

Why this template works:

• it already includes the special movement branch
• it separates target permissions from movement behavior
• it gives you clear places to tune travel distance, arrival behavior, and recovery

Best first edits:

• choose whether the grapple is for mobility, retrieval, or both
• tighten range_blocks and cooldown before adding fancy visuals
• decide whether players, mobs, items, or only blocks are allowed targets
• tune arrival distances before changing pull speed

Go deeper here:

• grapples and Tools
• input Binds, Consumables, and Alt Actions
• conditional Rules and Context-Aware Weapons

plantable_mountable_base.yml

This is the correct base for mounted launchers, deployable devices, mortar stations, and sky-select equipment.

id: NEW_PLANTABLE_DEVICE
enabled: true
category: PLANTABLE
tier: COMMON
classifications:
  - "%category%"
 
visual_key: mounted_device_alpha
 
plantable:
  enabled: true
  placement:
    allowed_faces: [up]
    max_range_blocks: 5
 
mountable:
  enabled: false
 
sky_select:
  enabled: false
  camera_height_blocks: 80
  max_radius_blocks: 96
  confirm_action: MORTAR_IF_AVAILABLE

Why this template works:

• it already separates placement, mounted behavior, and sky-select behavior
• it can stay a simple placeable prop or grow into a full support device
• it keeps the hardware flow readable instead of burying everything in the projectile block

Best first edits:

• decide whether the item is only plantable, only mountable, or both
• enable sky_select only if the device actually needs remote targeting
• keep the first version safe and simple before adding large payload chains

Go deeper here:

• sky Select, Airstrikes, and Support Callers
• explosive Payloads, Clusters, and Strike Recipes

Good template workflow

The cleanest build order is:

1. choose the right base template
2. rename the item and fix its identity blocks
3. make the item function with the smallest possible feature set
4. add sound, particles, visual states, and conditions only after the base item works
5. compare the finished file against a similar included example

That order prevents one of the most common Duck Shot problems: trying to tune polish on an item that still does not have a stable baseline.

Common template mistakes

Starting from a rifle for every item

This usually creates bloated throwables, ugly support tools, and hard-to-read utility devices.

Adding every advanced system on day one

A small clean base file is easier to debug than a huge file with ADS, recoil, visuals, conditional rules, explosive branches, and staged FX all at once.

Leaving the wrong classifications in place

If the template classification does not match the real item family, the item can end up in the wrong menu, wrong slot logic, or wrong lore placeholders.

Related pages

• create Wizard, Templates, and Knobs
• weapon File Structure
• weapon Archetype Recipes
• stage Templates for Sounds, Particles, and Conditions