Install, First Boot, and Admin Surfaces

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

The goal is not to build your whole encounter ecosystem in one sitting. The goal is to generate the files, confirm the admin surfaces, and prove one dependable NPC loop before you scale into patrols, spawners, and larger combat content.

First generated files to review

Before you build shell types or place world content, open:

• plugins/DuckShell/config.yml
• plugins/DuckShell/patrols.yml
• plugins/DuckShell/spawners.yml
• plugins/DuckShell/head_cache.yml

Those files already tell you how DuckShell wants the system split:

• global behavior belongs in config.yml
• route content belongs in patrols.yml
• persistent spawn content belongs in spawners.yml
• cached appearance state belongs in head_cache.yml

The admin surfaces that matter most

DuckShell is easiest to maintain when you use the same division the plugin itself uses:

• AI Director for global shell.ai.* defaults
• NPC Type Editor for per-shell-type identity and overrides
• Patrol GUI for route content
• Spawner Browser for persistent spawn points
• /duckshell or /npc for quick operator actions, debug toggles, spawn utilities, and inspection

The more clearly you separate those jobs, the easier later content becomes to reason about.

First-boot sanity pass

On a clean server, validate these first:

• presentation strategy is correct for your stack
• nameplates or speech bubbles render where you expect
• Duck Shot integration is detected if you plan to use real weapon pools
• patrol and spawner files save cleanly
• debug is off unless you are actively diagnosing something
• a simple spawned NPC can be created from the GUI or command surface without console noise

Suggested first test loop

Do one short proof pass before you build a whole town:

1. Spawn one basic hostile shell type.
2. Confirm it presents correctly.
3. Confirm it can acquire, search, and return cleanly.
4. Build one patrol route and one persistent spawner.
5. Run one corpse-loot check and one reload check.

If that simple loop is not stable yet, larger encounter authoring will only hide the real problem.

What not to do on day one

• Do not author every shell type before you trust the global AI defaults.
• Do not put patrol intent into spawners or spawner intent into patrols.
• Do not leave combat or awareness debug running during ordinary playtests.
• Do not tune presentation offsets for every NPC before the disguise strategy is settled.

Recommended next pages

• global Config, Runtime, and File Map
• shell Types, AI Director, and Combat Behavior
• patrols, Spawners, and Persistence