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

Loadouts, Support Items, and Classification Design

Turn classifications into real loadout logic, support-item routing, hotbar rules, and cleaner public item families.

Duck Shot classifications are not just menu tags. They help decide how items are grouped, how loadouts are limited, how lore is generated, and how whole item families behave.

This is the page to read when you want your content pack to feel organized instead of random.

What classifications actually control

From the example Duck Shot setup, classifications can drive:

  • display labels
  • placeholder-driven lore
  • grouping into roles or item families
  • hotbar limits
  • held-effect hooks
  • support-item routing

That is why this file matters so much. A weapon pack can have perfect gun stats and still feel messy if the classification layer is weak.

The example group structure is already telling you how to think

The default classifications.yml includes reusable groups like:

  • weapon_role
  • weapon_type
  • support_item
  • tools_item
  • attachment_item
  • heavy_slot

That is useful because it separates ideas that many packs accidentally mix together.

Example:

  • primary and secondary are role slots
  • rifle, shotgun, and sniper are weapon types
  • consumable, tool, and grapple are support or utility roles

Those are not the same design question, so they should not live in one flat bucket.

Primary and secondary are slot rules, not weapon personality

The default classifications file keeps primary and secondary inside weapon_role.

That means the server can answer:

  • how many of this type belong in the hotbar
  • what slot logic should apply

without confusing that with whether the item is:

  • a pistol
  • a sniper
  • a grapple

This is exactly the kind of separation that keeps bigger content packs sane.

Support items need their own language

The default file already includes dedicated support-friendly lanes:

  • consumable
  • tool
  • grapple
  • plantable
  • mountable
  • attachment

That matters because a support item should not feel like a failed rifle.

Examples:

  • BANDAGE.yml and ADVANCED_MED_KIT.yml belong in the consumable lane
  • DUQS_GRAPPLE_BASIC.yml belongs in the tool and grapple lane
  • MORTAR_STATION.yml belongs in plantable, mountable, and explosive
  • EXAMPLE_MOUNTED_MG.yml belongs in mountable and heavy_rifle

Lore placeholders are part of the public item feel

The example classification file exposes lore placeholders like:

  • {classification_first_display}
  • {classification_display_csv}
  • {classification_tags_csv}
  • {classification_groups_csv}

And it also includes reusable label placeholders like:

  • classified_label
  • requires_label
  • attachment_label
  • ammo_label

This is one of the cleanest systems in Duck Shot because it lets the pack speak consistently without manually retyping every label across every weapon.

Heavy-slot design is more than just a tag

The example heavy_slot group is especially important because it can pair with held effects and loadout pressure.

Practical example:

  • heavy_rifle can sit in a heavy lane
  • a heavy weapon can apply slow or burden effects while held
  • the server can still keep normal primary/secondary logic intact

That is a much cleaner design than trying to fake "heavy weapon feel" with recoil alone.

Hotbar limits are part of loadout identity

Duck Shot's global config supports category-based hotbar enforcement through item_categories.hotbar_limits.

That means classifications can do real gameplay work:

  • two primaries max
  • two secondaries max
  • custom category caps
  • player feedback when the hotbar exceeds the intended loadout

The important design lesson is this:

loadout rules belong in the same mental system as classifications, not as a random separate patchwork of commands and lore.

Good public loadout patterns

Traditional shooter loadout

Use:

  • one or two primary
  • one or two secondary
  • clean weapon_type tagging

This keeps the pack familiar and readable.

Support engineer loadout

Use:

  • one firearm lane
  • one or more support-item lanes like tool, plantable, or consumable
  • classifications that surface utility clearly

This keeps the player from feeling like they are carrying disguised junk.

Heavy gunner loadout

Use:

  • heavy_rifle
  • heavy_slot
  • held effects
  • stronger hotbar discipline

This is where the classification layer can do real balance work.

Utility specialist loadout

Use:

  • tool
  • grapple
  • consumable
  • plantable

This lets the loadout read as gear and battlefield utility instead of only damage output.

Plantable and mountable items should not be an afterthought

The example classifications already include:

  • plantable
  • mountable

That is a good sign that Duck Shot expects deployables to be first-class parts of the pack.

Use them when the item:

  • creates a world object
  • persists or packs up
  • expects interaction after placement
  • should feel like equipment, not a thrown explosive

Attachments deserve their own category too

The default attachment_item group is another good example of clean content-pack thinking.

An attachment should not:

  • clutter rifle lists
  • pretend to be a support item
  • share tool routing with grapples or stations

Keeping attachment items cleanly grouped makes crafting and upgrade flows much easier to understand later.

How to design a classification setup that still scales

  1. separate role from type
  2. create dedicated support sections
  3. use groups for shared behavior
  4. use placeholders for consistent presentation
  5. keep hotbar limits attached to real category ideas, not random ids

If you do that early, the pack grows cleanly.

If you skip it, the pack usually ends up with:

  • duplicated lore
  • messy menus
  • unclear slot rules
  • one-off balance exceptions everywhere

Common mistakes

Using classifications as flavor only

If the tags never help the menu, lore, limits, or effects, they are not doing enough work.

Mixing slot and type in one label

primary_rifle_fast is not a clean role or a clean type. It is a future maintenance problem.

Hiding support items inside firearm lanes

A bandage or mortar station should not read like a weird rifle variant.

Forgetting the player-side loadout story

The point of the system is not just tidy YAML. It is helping players understand what belongs where.