Skip to main content
Duck Shot wiki

Wiki

Duck Shot Wiki

Public setup, weapon authoring, combat systems, particles, admin help, and troubleshooting for Duck Shot.

Getting Started

Start here for installation, first boot, and your first working Duck Shot weapon.

Example Library and Pack Planning

Separate the public starter pack, the deeper example library, and your own server-only content so the docs stay honest and useful.

Server Operations

Handle permissions, runtime tools, integrations, and real troubleshooting on live servers.

Combat Systems

Sky Select, Airstrikes, and Support Callers

Configure targeting devices, airstrike markers, strike cases, and mortar stations in a way players can actually understand and use.

Duck Shot supports several kinds of support-call items, but they are not all the same job.

This page is the public guide to the support-caller side of Duck Shot:

  • Sky Select targeting
  • thrown airstrike markers
  • handheld strike cases
  • planted mortar callers
  • event-scale support items

Mounted guns are covered separately in mounted Guns and Deployable Emplacements, because a player-operated rig should not be explained the same way as a remote strike tool.

Start with the support model, not the spectacle

Before you copy any file, decide how the player is supposed to call the support action.

Duck Shot already includes the four main patterns:

Thrown marker

Use this when the player should throw the item first, let it land, and call the strike from that marked position.

Best example:

  • AIRSTRIKE_MARKER.yml

Handheld case or tablet

Use this when the player should open a targeting view directly while holding the item.

Best examples:

  • AIRSTRIKE_CASE.yml
  • AIRSTRIKE_NUKE_CASE.yml

Planted support station

Use this when the device should exist in the world and be operated from a committed position.

Best examples:

  • EXAMPLE_MORTAR_SKYSELECT.yml
  • MORTAR_STATION.yml

Event-scale support item

Use this when the item is supposed to feel rare, loud, and map-changing rather than routine.

Best example:

  • AIRSTRIKE_NUKE_CASE.yml

What Sky Select actually does

Sky Select is Duck Shot's overhead targeting session.

In player terms, it lets the user:

  1. open a targeting session
  2. move a cursor across the valid area
  3. zoom or fine-tune the target point
  4. confirm or cancel
  5. hand the result off to an airstrike or mortar branch

That means Sky Select is not a particle gimmick. It is the input layer for support items that need precision targeting.

The core sky_select shape

YAML
sky_select:
  enabled: true
  camera_height_blocks: 96
  max_radius_blocks: 140
  step_blocks: 3.0
  cursor_update_interval_ticks: 2
  cancel_on_sneak: true
  confirm_action: AIRSTRIKE_IF_AVAILABLE
  cursor_material: LIGHT_BLUE_STAINED_GLASS
  cursor_scale: 0.45

camera_height_blocks

How high the targeting camera sits.

Higher values feel more like a commander view. Lower values feel tighter and more local.

max_radius_blocks

How far away the player can target.

This is one of the biggest balance knobs on the whole support stack.

step_blocks

How far the cursor moves per adjustment step.

Smaller values are more precise. Larger values feel faster but rougher.

cursor_update_interval_ticks

How responsive the cursor feels while moving.

cancel_on_sneak

Good safety behavior for support items, especially expensive ones.

confirm_action

This decides which support branch actually runs after the target is confirmed.

The most common example values are:

  • AIRSTRIKE_IF_AVAILABLE
  • MORTAR_IF_AVAILABLE

The support files Duck Shot already includes

AIRSTRIKE_MARKER.yml

This is the quick battlefield flare pattern.

The player:

  • throws the item
  • watches it land
  • gets a warning window
  • watches the strike resolve from the marked point

Use it when the item should feel immediate and readable.

AIRSTRIKE_CASE.yml

This is the clean handheld commander pattern.

The player:

  • opens Sky Select
  • confirms a target line
  • calls a visible plane run

Use it when targeting precision matters more than throw rhythm.

AIRSTRIKE_NUKE_CASE.yml

This is the event-scale pattern.

The player:

  • opens a very large Sky Select session
  • confirms one huge payload
  • triggers long warnings, aircraft presentation, blast choreography, and aftermath systems

Use it for rare events, not for ordinary support tools.

EXAMPLE_MORTAR_SKYSELECT.yml

This is the smallest clean mortar tutorial.

Use it when you want to learn planted support without jumping straight to the full station file.

MORTAR_STATION.yml

This is the heavier tactical station example.

It adds public behavior like:

  • persistence
  • pack-up timing
  • open-sky placement safety
  • per-device concurrency
  • actual mortar flight settings
  • auto-pack timing

Use it when the device should feel like a battlefield object, not just a shortcut.

Copyable handheld strike example

Use this when you want a clean "open targeting and confirm" support item.

YAML
sky_select:
  enabled: true
  camera_height_blocks: 96
  max_radius_blocks: 120
  step_blocks: 2.5
  cursor_update_interval_ticks: 2
  cancel_on_sneak: true
  confirm_action: AIRSTRIKE_IF_AVAILABLE
  cursor_material: LIGHT_BLUE_STAINED_GLASS
  cursor_scale: 0.42
 
airstrike:
  enabled: true
  start_delay_ticks: 28
  waves: 2
  strikes_per_wave: 4
  radius_blocks: 9.0
  pattern: LINE
  telegraph:
    enabled: true
    duration_ticks: 22
  messages:
    confirmed: '<gold>Strike confirmed.</gold>'
    nearby_warning: '<red>Incoming strike nearby.</red>'

Why this is a good first support item:

  • the targeting loop is easy to read
  • the warning window is fair
  • the strike stays small enough to debug

Copyable mortar-station pattern

Use this when the player should operate a planted support device instead of a thrown item.

YAML
sky_select:
  enabled: true
  camera_height_blocks: 88
  max_radius_blocks: 100
  step_blocks: 2.0
  cursor_update_interval_ticks: 2
  cancel_on_sneak: true
  confirm_action: MORTAR_IF_AVAILABLE
 
allow_handheld_open: false
max_concurrent_users_per_device: 1
session_timeout_ticks: 200
auto_pack_after_confirm_ticks: 80
 
mortar:
  enabled: true
  flight_ticks: 42
  flight_ticks_per_block: 0.22
  arc_height_blocks: 26
  require_open_sky_for_placement: true
  detonate_on_block_collision: true
  detonate_on_projectile_collision: true

Why this works:

  • the item feels like equipment, not a magic remote
  • one user controls the device at a time
  • the shell flight still feels like artillery

Airstrike knobs that matter most

Across the example files, the main airstrike design lanes are:

  • start_delay_ticks
  • waves
  • strikes_per_wave
  • radius_blocks
  • height_blocks
  • pattern
  • telegraph
  • plane
  • payload
  • messages
  • limits

Those answer the real public questions:

  • how long players have to react
  • whether the strike is focused or spread
  • whether it feels like artillery, a strafing run, or an event
  • how many of these can exist safely at once

Pattern choice changes the whole item

LINE

Use when:

  • the player should call a sweep
  • aircraft presentation matters
  • the strike should cover a lane

SINGLE

Use when:

  • the item is about one major payload
  • the telegraph matters more than area coverage
  • the blast should feel singular and deliberate

That is why event-scale support items often use SINGLE instead of pretending to be ordinary clustered strikes.

Telegraphing is part of the design

Support callers feel much better when the warning is readable.

Use:

  • warning messages
  • cursor visibility
  • delay before impact
  • plane audio
  • payload audio
  • telegraph particles

If a support item can kill from above, players need a fair chance to understand what is happening.

Choose the right caller model

Use a thrown marker when:

  • the action should feel fast
  • the landing point should matter
  • players should read the strike from the ground up

Use a handheld case when:

  • precision targeting matters
  • the player should feel like a commander
  • you do not want the extra step of throwing a marker

Use a planted station when:

  • location commitment matters
  • the device should be shared or persistent
  • setup and pack-up timing are part of the fantasy

Use an event-scale case when:

  • the item should be rare
  • aftermath matters
  • the strike is supposed to change the battlefield, not just damage it

Common mistakes

Making the target radius huge before the cursor feels good

Range is not the first thing players feel. Cursor readability is.

Using the nuke file as a beginner template

That file is great proof of engine depth, but it is a terrible first support item.

Forgetting strike limits

Support items need concurrency and cooldown discipline or they turn into constant spam.

Hiding a planted device inside a handheld flow

If the item is supposed to be a station, let it behave like a station.