feature: webui, kobolcpp intergration memory, game module
This commit is contained in:
@@ -0,0 +1,153 @@
|
||||
# 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:
|
||||
```powershell
|
||||
$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.
|
||||
Reference in New Issue
Block a user