CIVIL-AI-SYSTEM Integration

When both DIALOGUE-SYSTEM and CIVIL-AI-SYSTEM are installed, an integration layer coordinates the two modules automatically.

This page explains what the integration provides and what changes compared to running Dialogue standalone.

The integration assembly

The integration lives in a separate assembly at Assets/BardTreeLtd/Integrations/CivilAI.Dialogue/. It is intentionally thin -- a single registrar that bridges the two modules.

CivilAIDialogueIntegrationRegistrar registers at Order 300, which means it runs after both the CivilAI registrar (Order 100) and the Dialogue registrar (Order 200). This ensures all services from both modules are available when the integration wires up.

What the integration provides

Agent control during conversations

The integration registers CivilConversationAgentControlPolicy as a multi-registration for IConversationAgentControlPolicy.

When a conversation starts, this policy pauses the agent's CivilAI behaviour tree. When the conversation ends, the behaviour tree resumes. This prevents agents from walking away, switching tasks, or performing work actions while they are in a conversation.

Without CivilAI, a no-op fallback is used and agents are not paused.

World clock

CIVIL-AI-SYSTEM is the canonical owner of IWorldClock when installed. The Dialogue module can consume this shared service for time-aware features.

When running standalone, the Dialogue registrar registers a fallback IWorldClock implementation that returns zero. This means time-dependent dialogue features will not function without CivilAI, but the system will not crash.

Item catalogue

The Dialogue editor checks for item collections through the shared IItemCatalog service before displaying its graph view. In practice, this means CivilAI item collections (item name, type, and size collections) need to be set up before the Dialogue editor works correctly.

This is why most combined projects should treat CivilAI setup as the foundation and Dialogue as a layer added on top.

Conversation triggers and sense

When CivilAI is installed, conversation trigger proximity detection can use the CivilAI sense system (ISenseProvider). This provides perception-profile-based spatial awareness rather than simple distance checks.

Setup order for combined projects

If you are using both modules:

1. set up BardTreeModuleBootstrap in the scene
2. configure CivilAI module settings and item collections
3. verify CivilAI agents spawn and simulate correctly
4. configure Dialogue module settings
5. create dialogue content and assign trees to agents
6. test conversations

For detailed CivilAI setup, see the Getting Started guide in the CIVIL-AI docs. For Dialogue-specific setup within a combined project, see the Dialogue Setup guide.

Running standalone

Dialogue works without CivilAI. The key differences when running standalone:

• agent behaviour trees are not paused during conversations (no behaviour trees exist)
• world clock returns zero (no world time simulation)
• item catalogue is not available (the Dialogue editor may show a warning)
• conversation triggers use simpler proximity detection

For standalone setups, use Shared + Dialogue as your install combination and configure dialogue agents directly without CivilAI population regions or buildings.

Practical advice

For most users building a medieval town with interactive NPCs, Shared + CivilAI + Dialogue is the recommended setup. The integration layer handles coordination automatically and you do not need to wire anything manually.

If you are building a project focused purely on conversation (a visual novel, an interview simulator, a dialogue prototype), standalone Dialogue is a valid and simpler starting point.