Wiki
DuckShell NPCs Wiki
NPC systems, patrols, spawners, combat AI, dialogue delivery, and live-server operations for the DuckShell stack.
Getting Started
Start here for first boot, file layout, and the admin surfaces that control the rest of the plugin.
AI and Combat
Separate global AI policy, per-type identity, awareness, cover, and personality presets without turning the roster into guesswork.
World Content
Keep patrol routes and persistent spawners as separate world systems with their own save files and editor workflows.
Presentation and Ecosystem
Handle disguises, skins, bubbles, dialogue delivery, and cross-plugin cooperation without burying those concerns in AI pages.
Runtime and Troubleshooting
Run live-server debug, Spark, corpse-loot checks, and civilian-arming validation without losing track of the real problem.
Presentation, Skins, and integration bridges
DuckShell is not only an AI system. It also owns how NPCs look, how they communicate, and how they cooperate with the rest of the Block Arsenal stack.
Presentation strategy
The top of config.yml starts with a dedicated presentation layer. That is your first clue that appearance is meant to be configurable, not hardcoded forever.
Key presentation concerns include:
- disguise strategy
- hand and nameplate behavior
- shell offsets
- speech bubble or nameplate rendering
- skin and head caching
Why presentation is a real system
Presentation mistakes can look like AI bugs when they are really display problems:
- bad offsets make hints look jittery
- wrong disguise state makes hitboxes feel incorrect
- stale cache data can make skins appear inconsistent
Treat presentation as its own lane and test it separately from combat behavior.
Skin and head cache
head_cache.yml exists to store cached texture-profile data so the plugin does not have to rediscover the same appearance data constantly. This is a performance and reliability system, not only a cosmetic detail.
The main integration bridges
DuckShell is designed to sit beside other systems instead of pretending it is the only plugin in the stack.
The most important bridges today are:
- Duck Shot for weapons, projectiles, utilities, and loot identity
- SoundLogic for noise and investigate pull
- radios or event systems for world-event behavior and takeover content
- presentation dependencies such as LibsDisguises and ProtocolLib
Depending on your stack, MythicMobs compatibility and separation can also matter operationally, especially when you want DuckShell NPCs to coexist without being misclassified as Mythic-owned content.
Practical rule for bridge work
If a bug changes how the NPC behaves in combat, pathing, or loot, document it in the DuckShell lane.
If a bug only changes the underlying item, projectile, or world-event emitter, document that bridge clearly instead of hiding it inside a generic NPC note.
That keeps cross-plugin ownership clear.