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.

Weapon Authoring

Per-Weapon Sounds, Events, and Breath Focus

Tune the per-weapon sound lanes, spatial audio, world-event audio, and hold-breath focus behavior at a much more granular level.

This page exists for one big reason:

Duck Shot already exposes a lot more per-weapon sound and event control than most people realize.

If you want weapons to feel premium, believable, tense, or highly stylized, this is one of the most important pages in the whole wiki.

The big answer first

Duck Shot already exposes a large amount of weapon feel as independent per-weapon config.

That includes:

  • base shoot sound
  • empty sound
  • ADS sound
  • impact sound
  • underwater impact sound
  • flyby sound
  • spatial audio behavior
  • world event audio
  • staged action and reload sounds
  • hold-breath inhale, heartbeat, and exhale sounds on supported weapons

The one place that still works best through nearby event routing instead of its own dedicated block is breath-stage visual FX. For that, the cleanest current path is to combine scoped weapon behavior with weapon_events, conditions, and particles_v2.events.

The core weapon sound lanes

Example weapons already expose sound blocks like these:

YAML
sounds:
  shoot:
    audience: WORLD
    stages:
      - time: 0
        key: 'minecraft:gunshot'
        volume: 1
        pitch: 1
  empty:
    audience: PLAYER
    stages:
      - time: 0
        key: 'minecraft:item.flintandsteel.use'
        volume: 1
        pitch: 2
  ads:
    audience: PLAYER
    stages:
      - time: 0
        key: 'minecraft:entity.bat.takeoff'
        volume: 1
        pitch: 2
  impact:
    key: 'minecraft:entity.arrow.hit'
    volume: 0.8
    pitch: 1.0
  impact_underwater:
    key: 'minecraft:bullet.water'
    volume: 0.8
    pitch: 1.0
  flyby:
    enabled: true
    radius: 4.5
    cooldown_ticks: 6
    every_ticks: 1
    key: 'minecraft:bullet.whiz'
    volume: 0.6
    pitch: 1.0

That already lets you separate:

  • what the shooter hears
  • what the world hears
  • what a near miss sounds like
  • what the impact sounds like in water vs normal space

Why staged sound matters

Duck Shot is not limited to one flat sound file per event.

Staged sounds let you author:

  • a main report
  • a delayed tail
  • a layered mechanical clack
  • a secondary sound for the world only

That is one of the cleanest ways to make weapons feel rich without making the config unreadable.

Spatial audio is its own major system

Per-weapon sounds.spatial already supports much more than a simple distance fade.

The example structure includes lanes like:

YAML
sounds:
  spatial:
    enabled: true
    distance_cap: 720.0
    near_max: 30.0
    mid_max: 65.0
    far_max: 90.0
    crack_min: 130.0
    crack_max: 500.0
    distant_crack:
      enabled: true
      key: minecraft:distantshot
      volume: 1.0
      pitch: 1.0
    muffled:
      enabled: true
      key: minecraft:muffleshot
      volume_mult: 0.72
      suppress_crack_when_muffled: true
      suppress_secondary_stages: true
    silenced:
      cross_boundary_mute: false
      allow_shooter_underwater_cue: true
      allow_nearby_underwater_cue: true
      nearby_underwater_radius: 7.0
      disable_distant_crack: false
    world_events:
      enabled: true
      reload_enabled: true
      action_enabled: true
      reload_distance_cap: 15.0
      action_distance_cap: 15.0
      mute_when_occluded: true
      mute_underwater: true
    indoor:
      enabled: true
      skylight_threshold: 1

This means per-weapon sound design is not only about "what sound key do I use." It is also about:

  • how that weapon behaves indoors
  • how it cracks at distance
  • how it gets muffled
  • how silenced behavior is treated
  • whether reload and action sounds become world events

Breath sway and hold breath

Scoped weapons with breath control already expose a meaningful per-weapon configuration lane.

Real example shape:

YAML
aim:
  enabled: true
  zoom_levels:
    - 3.0
    - 10.0
  movement_speed_multiplier: 0.85
  breath_sway:
    enabled: true
    update_period_ticks: 1
    amplitude_degrees: 5.20
    frequency_hz: 0.12
    ellipse_ratio: 0.60
    random_phase: true
    hold_breath:
      enabled: true
      focus_multiplier: 0.05
      stamina_max: 140
      drain_per_tick: 1
      recover_per_tick: 2
      min_stamina_to_start: 10
      break_burst_amplitude_degrees: 3.52
      break_burst_ticks: 20
      lockout_ticks: 40
      refocus_cooldown_ticks: 20
      force_unsneak_on_break: true
      heartbeat_interval_ticks: 20
      max_heartbeats: 6
      heartbeat_pitch_end: 0.8
      final_heartbeat_gap_ticks: 20
      sounds:
        inhale: minecraft:breathin
        heartbeat: minecraft:heartbeat
        exhale: minecraft:breathout

What that breath block already gives you

This is the important part for advanced weapon feel.

You can already change, per weapon:

  • sway amplitude
  • sway rhythm
  • ellipse ratio
  • whether phase is randomized
  • how strong hold-breath focus becomes
  • how much stamina the player gets
  • how fast stamina drains and recovers
  • how dramatic the break-burst is
  • how long lockout lasts
  • how quickly refocus returns
  • whether the player is forced out of sneak on break
  • inhale sound
  • heartbeat sound
  • exhale sound
  • heartbeat timing and pitch progression

So if your question is "can one sniper have a different inhale/heartbeat/exhale personality than another one?" the answer is yes.

Event-by-event sound control is already real

The current example files also show that Duck Shot can route conditional sound changes on specific events instead of only relying on one static weapon sound set.

From the conditional test weapon:

YAML
conditions:
  rules:
    - id: fx_secondary_fire_red_glazed
      events: [shoot]
      when:
        standing_on_materials: [red_glazed_terracotta]
      actions:
        effects:
          mute_default_shoot_sound: true
          mute_default_muzzle: true
          mute_default_shot_events: true
          weapon_events: [cond_muzzle_swap, cond_trail_swap]
          sounds:
            - time: 0
              key: minecraft:entity.firework_rocket.launch
              volume: 0.9
              pitch: 1.35
              audience: PLAYER
            - time: 2
              key: minecraft:block.amethyst_block.hit
              volume: 0.7
              pitch: 1.6
              audience: WORLD

That matters because it proves the sound design can already react to:

  • footing
  • stance
  • light level
  • event type
  • whether you want to keep or mute the default sound lanes

This is exactly the level of per-event control most advanced servers want.

What can be independently tuned per weapon

At a practical level, a single weapon can already own different sound identities for:

  • draw and action sounds
  • ADS sounds
  • shoot and delayed shoot stages
  • empty trigger response
  • impact and underwater impact
  • flyby behavior
  • spatial crack and muffle behavior
  • world-event action and reload sounds
  • hold-breath inhale, heartbeat, and exhale
  • condition-specific replacement or additive sound stacks

That is why the plugin does not need a separate "sound profile file" to feel rich. The weapon file already has a lot of that surface.

Breath focus example you can copy and adapt

YAML
aim:
  enabled: true
  zoom_levels:
    - 3.0
    - 10.0
  movement_speed_multiplier: 0.85
  breath_sway:
    enabled: true
    update_period_ticks: 1
    amplitude_degrees: 5.20
    frequency_hz: 0.12
    ellipse_ratio: 0.60
    random_phase: true
    hold_breath:
      enabled: true
      focus_multiplier: 0.05
      stamina_max: 140
      drain_per_tick: 1
      recover_per_tick: 2
      min_stamina_to_start: 10
      break_burst_amplitude_degrees: 3.52
      break_burst_ticks: 20
      lockout_ticks: 40
      refocus_cooldown_ticks: 20
      force_unsneak_on_break: true
      heartbeat_interval_ticks: 20
      max_heartbeats: 6
      heartbeat_pitch_end: 0.8
      final_heartbeat_gap_ticks: 20
      sounds:
        inhale: minecraft:breathin
        heartbeat: minecraft:heartbeat
        exhale: minecraft:breathout

Interpretation:

  • focus_multiplier controls how calm the sight picture becomes
  • stamina_max, drain, and recovery define how punishing the mechanic feels
  • the three sound keys let one sniper sound clinical and another sound heavy or panicked

The practical split between sounds and particles

For weapon sounds, the direct config surface is already deep.

For richer visuals, the modern path is:

  1. keep the sound logic in the weapon
  2. emit weapon_events when needed
  3. bind those event ids into particles_v2.events

That keeps the weapon readable while still letting you build big visual stacks for:

  • ADS overlays
  • muzzle swaps
  • impact profile swaps
  • low-light or environment-specific FX

Breath visuals today

The hold_breath.sounds block is mainly an audio lane, but you can still build convincing breath visuals today by routing nearby weapon behavior into reusable FX.

The cleanest options are:

  • use ADS start and ADS exit events for entry and release visuals
  • use condition rules to branch scoped effects by stance, block, water, or movement state
  • use weapon_events and particles_v2.events for reusable inhale-style or heartbeat-style overlays
  • keep the breath visual stack light so it supports the sight picture instead of obscuring it

That approach keeps the weapon readable while still letting one sniper feel calm, another feel heavy, and another feel panicked or high-pressure.

Copyable weapon-focused example

This is a good public pattern for a scoped weapon that needs its own emotional sound language.

YAML
sounds:
  ads:
    audience: PLAYER
    stages:
      - time: 0
        key: minecraft:block.amethyst_cluster.hit
        volume: 0.4
        pitch: 1.8
  impact:
    key: minecraft:entity.arrow.hit
    volume: 0.7
    pitch: 0.95
  impact_underwater:
    key: minecraft:bullet.water
    volume: 0.8
    pitch: 0.9
aim:
  breath_sway:
    enabled: true
    amplitude_degrees: 4.2
    frequency_hz: 0.11
    hold_breath:
      enabled: true
      focus_multiplier: 0.04
      stamina_max: 160
      drain_per_tick: 1
      recover_per_tick: 2
      lockout_ticks: 35
      sounds:
        inhale: minecraft:breathin
        heartbeat: minecraft:heartbeat
        exhale: minecraft:breathout

Interpretation:

  • softer ADS cue
  • cleaner impact profile
  • slower calmer breath control
  • stronger precision reward during the focus window

Use conditions for extra event-specific behavior

If you want a sound or FX branch that only happens in a specific context, combine the per-weapon sound system with the condition system.

That gives you things like:

  • different ADS overlay in low skylight
  • different reload sounds on a specific block type
  • different shot tails when sneaking or sprinting

See conditional Rules and Context-Aware Weapons for that layer.

  1. make the base weapon readable with good shoot, ADS, impact, and reload sound lanes
  2. tune spatial audio only after the core weapon already feels right
  3. add hold-breath sound personality on scoped weapons
  4. use condition-driven weapon_events for context-specific sound or FX swaps
  5. only escalate to source changes when the needed event is truly not exposed yet