How stoopkid713/stoop works
1. System shape
- STOOP is a local desktop log analyzer plus a remote party-sync service.
- The local app reads Throne & Liberty combat logs from disk, computes stats, and renders the UI.
- The remote service is only for shared Party DPS state, invites, and board synchronization.
2. Primary data source boundary
- The only game input is the Detailed Combat Log written by T&L to %LOCALAPPDATA%/TL/Saved/CombatLogs.
- The app does not inject into the game, hook graphics, or read game memory; everything starts from log files on disk.
3. Local ingestion pipeline
- backend/log_watcher.py monitors the log file.
- backend/combat_log_parser.py converts raw log lines into structured combat events.
- backend/encounter_scan.py and backend/encounter_boundary.py decide where fights start/end.
- backend/combat_stats.py, backend/party_state.py, and related modules aggregate damage, crit/heavy rates, party membership, and encounter summaries.
4. Local application runtime
- backend/main.py is the desktop app entry point and orchestration layer.
- backend/dps_meter_server.py provides the local server/API that the UI talks to.
- backend/hotkey.py, backend/debug.py, and backend/party_state.py support interaction, resets, and diagnostic flows.
- backend/persistence.py manages the app’s JSON state files.
5. Local persistent state
- User and combat data are stored as JSON in the app data folder.
- Key persisted artifacts include config.json, encounters.json, saved_runs.json, skill_settings.json, weapon_config.json, default_target_assignments.json, and dungeons.json.
- This persistence layer is the boundary between transient combat events and long-lived build/run history.
6. Frontend/UI layer
- The main UI is a browser-based frontend built from index.html, party_render.js, and modules under src/js/.
- Those modules cover party display, encounter editing, run building, saved runs, skill/rotation analysis, target assignment, and drill-down views.
- The frontend is the presentation layer; it consumes data from the local backend and reflects persisted state.
7. Overlay subsystem
- overlay/src-tauri is a separate Tauri/Rust app that provides the in-game overlay window.
- Its architectural role is distinct from the main UI: a transparent, click-through overlay that displays the live party board over the game.
- The overlay is a separate process/window boundary, not part of the game client.
8. Party DPS remote service
- workers/party is the cloud backend for shared party functionality, deployed as a Cloudflare Worker.
- It handles party/dashboard synchronization, invite codes/links, analytics, feedback, and game-data endpoints.
- Local clients push or fetch party state through this service so multiple players can contribute to one shared scoreboard.
9. Build/data-refresh tooling
- backend/build.py packages the desktop app with PyInstaller and optional Inno Setup installer creation.
- backend/tools/refresh_game_data.py and the worker-side game-data code support refreshing metadata used by the UI and analysis.
- Repo-level JSON fixtures and samples are used to validate parsing and encounter behavior.
10. Testing architecture
- Backend logic is covered by Python unit tests in backend/tests/.
- UI behavior is covered by browser tests in tests/frontend/.
- Party-service behavior is covered by worker tests in workers/party/test/.
- End-to-end robustness is exercised by battery scenarios in tests/battery/, which simulate multi-client, overlay, race, reconnect, and adversarial conditions.
11. Key end-to-end flows
- Solo analysis flow: log file → watcher/parser → encounter/stats aggregation → persistence → local UI.
- Party flow: each player’s local app parses their own logs → stats are merged/synchronized via the worker → shared board is shown locally and in the overlay.
- Review flow: persisted encounters/runs are reopened in the UI for drill-down, comparison, and build analysis.
12. Operational boundaries
- GitHub Actions handles CI and release packaging.
- The cloud worker is the only remote runtime involved in product features; everything else is local desktop processing.
- The repo is therefore a multi-runtime desktop system: Python backend, browser UI, Rust overlay, and serverless party infrastructure.
Main entry points: index.html Main UI · index.js Party worker · main.py App entry · dps_meter_server.py Local API
Components 21
Local backend
Python desktop runtime that ingests logs, computes stats, persists state, and serves the local API.
- App entry · Desktop application entry point and orchestration layer.
backend/main.py - Log watcher · Monitors the combat log file on disk.
backend/log_watcher.py - Parser · Converts raw combat log lines into structured events.
backend/combat_log_parser.py - Encounter scan · Detects encounter boundaries and fight segmentation.
backend/encounter_scan.py - Combat stats · Aggregates damage, crit rates, summaries, and related encounter metrics.
backend/combat_stats.py - Party state · Tracks party membership, encounter state, and shared DPS board data.
backend/party_state.py - Persistence · Reads and writes the app's persisted JSON state files.
backend/persistence.py - Local API · Local server/API used by the UI and overlay-facing flows.
backend/dps_meter_server.py
Frontend UI
Browser-based presentation layer for party, encounters, runs, and analysis views.
- Main UI · Browser-based frontend shell for the desktop application.
index.html - Party view · Party board and live combat presentation logic.
src/js/party.js - Run builder · Builds, edits, and compares saved runs and encounter views.
src/js/run-builder.js - Targets · Target assignment and analysis views for encounters and rotations.
src/js/targets-assign.js
Overlay
Separate Tauri/Rust overlay window for in-game party board display.
- Overlay app · Transparent, click-through overlay window for shared party display.
overlay/src-tauri/src/main.rs
Cloud worker
Remote party-sync service and game-data endpoints deployed as a Cloudflare Worker.
- Party worker · Remote sync entry point for party/dashboard functionality.
workers/party/src/index.js - Dashboard sync · Handles invite, party board, and dashboard synchronization logic.
workers/party/src/dashboard.js - Game data · Serves game-data and analytics endpoints used by the UI and sync service.
workers/party/src/gamedata.js
Tests
Backend, frontend, worker, and end-to-end validation suites.
- Battery tests · Multi-client, overlay, race, reconnect, and adversarial end-to-end scenarios.
tests/battery/runner.js - Frontend tests · Browser-based UI behavior and capture tests.
tests/frontend/harness.js - Worker tests · Cloud worker behavior and dashboard analytics validation.
workers/party/test/dashboard_analytics.test.mjs
Tooling
Packaging and data-refresh utilities.
- Build packager · Packages the desktop app with PyInstaller and installer tooling.
backend/build.py - Data refresh · Refreshes game metadata used by the app and worker.
backend/tools/refresh_game_data.py
Connections 22
- App entry → Log watcher: watches · Starts log monitoring for the on-disk combat log.
- Log watcher → Parser: raw lines · Feeds raw log lines into structured parsing.
- Parser → Encounter scan: events · Parsed combat events are scanned for fight boundaries.
- Encounter scan → Combat stats: segments · Encounter segments are aggregated into combat stats.
- Combat stats → Party state: summaries · Computed encounter and party summaries update shared state.
- Party state → Persistence: save/load · Long-lived party, run, and configuration state is persisted.
- App entry → Local API: serves · Orchestrates the local API consumed by the UI.
- Local API → Main UI: data · UI reads state and live updates from the local server.
- Main UI → Party view: loads · Main shell loads the party board presentation module.
- Main UI → Run builder: loads · Main shell loads run editing and comparison views.
- Main UI → Targets: loads · Main shell loads target assignment and analysis views.
- Local API → Overlay app: overlay feed · Overlay consumes live board state from the local runtime.
- Party state → Party worker: syncs · Local party state is pushed to or fetched from the remote sync service.
- Party worker → Dashboard sync: routes · Routes party and dashboard synchronization requests.
- Party worker → Game data: serves · Exposes analytics and game-data endpoints.
- App entry → Build packager: packages · Desktop app is packaged through the build pipeline.
- App entry → Data refresh: refreshes · Build/runtime tooling refreshes metadata used by analysis.
- Battery tests → Local API: exercises · End-to-end scenarios drive the local backend and sync flows.
- Battery tests → Party worker: exercises · Battery scenarios validate party-sync behavior against the worker.
- Frontend tests → Main UI: verifies · Browser tests verify UI behavior and rendering.
- Worker tests → Party worker: verifies · Worker tests validate cloud sync behavior.
- Data refresh → Game data: feeds · Metadata refresh tooling supports worker game-data endpoints.