
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.
Weapon Authoring
Learn the actual weapon-file structure, support files, and player-side feedback systems.
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.
Combat Systems
Tune firing, impacts, special utility items, and the Particles v2 effect stack.
Server Operations
Handle permissions, runtime tools, integrations, and real troubleshooting on live servers.
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_roleweapon_typesupport_itemtools_itemattachment_itemheavy_slot
That is useful because it separates ideas that many packs accidentally mix together.
Example:
primaryandsecondaryare role slotsrifle,shotgun, andsniperare weapon typesconsumable,tool, andgrappleare 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:
consumabletoolgrappleplantablemountableattachment
That matters because a support item should not feel like a failed rifle.
Examples:
BANDAGE.ymlandADVANCED_MED_KIT.ymlbelong in theconsumablelaneDUQS_GRAPPLE_BASIC.ymlbelongs in thetoolandgrapplelaneMORTAR_STATION.ymlbelongs inplantable,mountable, andexplosiveEXAMPLE_MOUNTED_MG.ymlbelongs inmountableandheavy_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_labelrequires_labelattachment_labelammo_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_riflecan 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_typetagging
This keeps the pack familiar and readable.
Support engineer loadout
Use:
- one firearm lane
- one or more support-item lanes like
tool,plantable, orconsumable - classifications that surface utility clearly
This keeps the player from feeling like they are carrying disguised junk.
Heavy gunner loadout
Use:
heavy_rifleheavy_slot- held effects
- stronger hotbar discipline
This is where the classification layer can do real balance work.
Utility specialist loadout
Use:
toolgrappleconsumableplantable
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:
plantablemountable
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
- separate role from type
- create dedicated support sections
- use groups for shared behavior
- use placeholders for consistent presentation
- 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.

