Debug, Performance, Corpses, and Live Ops

DuckShell live-server work is not only about "does the NPC move." The real operator loop is:

• spawn the content
• run the encounter
• capture debug and Spark data
• decide whether the issue is AI, bridge, presentation, or world content

This page is the operating guide for that loop.

The command surface

From plugin.yml, the main admin command is:

/duckshell

Aliases include:

/npc
/duqshell
/dshell

That command surface is used for:

• reload
• debug
• spawn
• gui or menu access
• list and inspect actions

Use debug intentionally

DuckShell's current runtime notes already call out awareness and combat debug as important tools. Use them for controlled tests, not as a permanent server setting.

Good debug passes usually pair:

• one clear test scenario
• combat and awareness logs
• a Spark profile
• a note about NPC count and map conditions

That gives you something actionable instead of a giant log with no test shape.

Performance philosophy

The DuckShell runtime has already moved several heavy debug outputs off the main thread, but large encounter tests still need discipline.

When you profile:

• separate player-versus-NPC tests from NPC-versus-NPC tests
• note whether companions are involved
• note whether event systems are also spawning content
• note whether debug was enabled the entire time

That is how you tell the difference between a real runtime cost and a test harness cost.

Corpse containers and additive drops

DuckShell corpse handling is part of the gameplay surface. Current behavior can include:

• a dead-body loot container
• additive drop add-ons on top of base loot
• exact equipped-weapon returns for certain runtime-armed civilians
• actual worn armor or carried utility being inserted into the corpse inventory

That means corpse-loot tests are a required part of shell-type validation, especially for civilians or companions that can be armed at runtime.

Civilian arming and return-on-death logic

DuckShell's civilian arming flow is especially important for types such as wanderers or prisoners:

• they should not spawn armed by default
• they can be given a valid weapon by a player
• conversion and recruitment should preserve that runtime-armed state
• corpse loot should be able to return the handed weapon when that design is intended

This is one of the clearest cases where shell authoring, bridge logic, and corpse behavior all meet.

A practical live-server checklist

Before you call an encounter setup stable, verify:

1. the shell type spawns with the right identity
2. investigate, combat, and return all make sense
3. patrol or spawner persistence behaves correctly
4. dialogue and hints render correctly
5. corpse loot matches the design
6. Spark looks acceptable for the actual NPC count you care about

Recommended next pages

• shell Types, AI Director, and Combat Behavior
• patrols, Spawners, and Persistence