LocalDiplomacy/docs/LocalDiplomacy_IMPLEMENTATION_STATUS.md

LocalDiplomacy Implementation Status

Last updated: 2026-04-30

Working / Implemented

Bannerlord Module

• Module folder exists at module/LocalDiplomacy.
• SubModule.xml is present and configured for singleplayer.
• Module builds to:
  • module/LocalDiplomacy/bin/Win64_Shipping_Client/LocalDiplomacy.dll
• Current dependencies:
  • Native
  • SandBoxCore
  • Sandbox
  • StoryMode
• LocalDiplomacy.SubModule loads in Bannerlord.
• Campaign behavior is registered on campaign game start.
• Dedicated game-side log exists:
  • Documents/Mount and Blade II Bannerlord/Configs/ModLogs/LocalDiplomacy.log
• Dialogue hook is registered for several conversation tokens:
  • lord_pretalk
  • lord_talk
  • lord_talk_speak_diplomacy_2
  • hero_main_options
  • hero_talk
  • start
• In-game dialogue option exists:
  • [LocalDiplomacy] Ask what news they have.
• Selecting the dialogue option sends a compact ConversationRequest to the local Python agent.
• Game client is hardcoded to call:
  • http://127.0.0.1:8766
• Game client logs outgoing payloads and failed HTTP responses.
• Agent responses are displayed in-game with InformationManager.DisplayMessage.
• Returned game actions are passed through local validation before execution.
• Action executor currently displays accepted actions as messages.

Python Agent

• FastAPI agent exists at src/LocalDiplomacy.Agent.
• Agent runs with uv.
• Main app module:
  • localdiplomacy_agent.app:app
• Main endpoints implemented:
  • GET /health
  • GET /debug/status
  • POST /conversation/respond
  • POST /world/tick
  • POST /actions/result
• Web dashboard exists:
  • http://127.0.0.1:8766/ui
• Dashboard shows:
  • agent status
  • KoboldCpp reachability
  • memory status
  • last latency
  • live logs
  • KoboldCpp API address
  • model id
  • timeout
• Dashboard can update KoboldCpp API settings.
• Dashboard can ping KoboldCpp.
• KoboldCpp API can point at another machine, for example:
  • http://192.168.1.17:5001
• Agent logs game requests, agent replies, queued actions, warnings, and errors.
• Agent config persists to config.yaml.
• Agent supports /no_think prompt prefixing for Qwen3-style thinking models.
• Agent uses focused tool selection for action-looking requests.
• Agent uses narrowed action schemas for small models.
• Agent can force propose_game_action tool calls for explicit action requests.
• Python contract accepts C#-style nullable traits.
• Memory layer scaffold exists and currently defaults to disabled.
• SQLite event ledger exists.

KoboldCpp / Model Testing

• KoboldCpp OpenAI-compatible /v1/chat/completions flow is implemented.
• Tool calling uses OpenAI-style tools and tool_choice.
• Model smoke-test script exists:
  • scripts/test_kobold_model.py
• Smoke-test script accepts:
  • model path
  • context size
  • KoboldCpp path
  • port
  • keep-running flag
  • stop-existing flag
  • extra KoboldCpp args
• Smoke-test script runs:
  • normal dialogue test
  • auto tool-call test
  • forced tool-call test
  • LocalDiplomacy action-planner tool-call test
• Qwen3-4B-abliterated-q4_k_m.gguf was tested at 40960 context and passed smoke tests with /no_think.

Tests / Build

• Python test suite passes.
• Current Python test count:
  • 11 tests
• C# module builds successfully with local .NET SDK and Bannerlord references.
• Build command:

  $env:PATH="$env:USERPROFILE\.dotnet;$env:PATH"
  $env:BANNERLORD_REFERENCES="D:\SteamLibrary\steamapps\common\Mount & Blade II Bannerlord\bin\Win64_Shipping_Client"
  dotnet build src\LocalDiplomacy\LocalDiplomacy.csproj
  

Partially Implemented / Scaffolded

Bannerlord Gameplay Integration

• Dialogue integration is currently a single debug-style option.
• Player cannot yet type custom dialogue text inside Bannerlord.
• NPC answer is currently displayed as an information message, not as a full custom conversation UI.
• No Gauntlet UI has been built inside the game.
• No confirmation UI exists yet for dangerous actions.
• Local validation exists, but most action-specific validation is still basic.
• Action execution is mostly placeholder behavior.
• World tick endpoint exists, but the game does not yet send rich world diffs.
• Nearby parties, settlements, kingdom state, and recent events are still minimal in the in-game request.

Agent

• Tool registry contains broad AIInfluence-style feature coverage.
• Many tools are declared but backed by placeholder/read-only behavior until the Bannerlord connector supplies richer live data.
• Memory storage is scaffolded but disabled by default.
• Mem0 + Qdrant is planned but not wired as the default runtime path yet.
• No separate desktop UI exists; the current UI is browser-based FastAPI HTML.

Known Issues / Watch Items

• Small models can narrate tool intentions unless /no_think, narrowed schemas, and forced tool calls are used.
• Full tool catalog is too large for reliable 4B model tool choice.
• The Python dashboard updates KoboldCpp settings at runtime, but active in-flight calls use the currently loaded config object.
• Bannerlord must be closed before rebuilding if the DLL is locked.
• The first working in-game path depends on the player selecting the debug dialogue option.
• Returned action execution is intentionally conservative and mostly non-mutating.

Next Recommended Work

1. Replace the debug prompt with a small in-game text input or selectable prompt menu.
2. Show NPC responses in a proper dialogue/inquiry window instead of only notification messages.
3. Expand BuildDebugConversationRequest with real nearby parties, settlement, war, clan, and kingdom context.
4. Add confirmation UI for diplomacy, hostile, and high-impact actions.
5. Implement a small set of real Bannerlord mutations:
   • follow player
   • patrol settlement
   • propose peace
   • declare war proposal validation only
6. Wire world tick diffs from Bannerlord to the agent.
7. Enable Mem0 + Qdrant memory once the dialogue loop is stable.