Install and First Boot

Use this page when Duck Shot is about to come online for the first time on a real server.

The goal is simple: get a clean first boot, understand the file surface that was generated, and prove one dependable combat loop before you start expanding into the rest of the arsenal.

If you are deciding which bundled content should come with your release, keep Public and Server Release Distributions open beside this page. The public and server jars now come from one shared pipeline, but they intentionally install different bundled rosters.

What to expect on first boot

Duck Shot should generate a readable file surface that already hints at how the plugin wants to be authored:

• config.yml
• weapons/*.yml
• ammos.yml
• attachments.yml
• classifications.yml
• gui.yml
• integrations.yml
• particles.yml
• particles_presets.yml
• projectiles.yml
• spread_patterns.yml
• visual_states.yml

That split is one of the most important things to understand early. It keeps global behavior, item definitions, shared support files, and presentation systems from turning into one giant editing mess.

Recommended first-boot flow

1. Stop the server.
2. Drop the Duck Shot jar into plugins/.
3. Start the server once and let the folder generate.
4. Read the startup summary in console before touching any files.
5. Stop the server again before making serious edits.

First sanity checks

Confirm the plugin actually loaded

Look for the Duck Shot startup summary in console. If startup fails, the first things to check are:

• server version compatibility
• damaged YAML from earlier edits
• another plugin breaking boot or command registration

Confirm the commands exist

Duck Shot should register its main command surface, including:

• /duckshot
• /ds
• /shot
• /gun
• /guns

If those commands do not exist, the plugin is not ready for live testing yet.

Prove one simple item loop

Hand yourself one known working example item and confirm:

• the item appears with the right material and model
• the action bar updates while holding it
• reload, aim, or firing behavior actually responds

That first proof matters more than a huge feature list. Once one real item works, the rest of the authoring flow becomes much easier to trust.

Settings worth reviewing immediately

Item identification

Duck Shot is designed to avoid the "random vanilla item became a gun" problem. These settings deserve an early check:

strict_item_identification: true
auto_tag_ammo_items: true

For most live servers, strict identification should stay on.

Reload input

The default reload trigger is:

reload_trigger: DROP_KEY

If your player base needs a different input style, make that decision early so your first test loop already reflects the real control scheme.

Action bar visibility

Duck Shot ships with the action bar enabled:

action_bar:
  enabled: true

That is one of the fastest ways to tell whether the plugin is reading held items and combat state correctly.

Safe first edits

These are good low-risk changes before you start authoring a whole arsenal:

• confirm integrations.yml only reflects the bridges you actually use
• review action-bar styling so feedback is readable
• review particle and sound limits before you chase spectacle
• keep your first test weapon simple enough to debug quickly

What not to do on day one

• Do not enable every specialty lane before one basic weapon already works.
• Do not start by rewriting the whole starter pack.
• Do not pile on throwables, support callers, explosives, and visuals before the core loop feels stable.
• Do not guess at a broken first boot when the console and commands can already tell you what failed.

Recommended next pages

• global Config and Runtime
• first Weapon Walkthrough
• weapon File Structure
• integrations and Troubleshooting