Moto/UnrealPrototyping
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Step 2: the telemetry seam

Browse Source 
ITelemetrySink with the null, log and JSON Lines sinks, FTelemetryEvent and the envelope, TelemetryEvents,
UTelemetrySubsystem on the game instance, ASaltyGameMode minting the session id into the replicated
ASaltyGameState, bs.TelemetryTest, the git hash in the build string (D-42) and four Salty.Core.Telemetry tests
replacing the placeholder. Proved standalone and with a headless server plus client sharing one session id.

Also enables the engine's Editor, AutomationTest, GameplayTags, ConfigSettings and LiveCoding MCP toolsets
(D-43) so the editor's MCP server exposes more than the skills toolset.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Rainer Leit
2026-09-16 20:22:20 +03:00
co-authored by Claude Fable 5.1
parent 4f2c55cd2a
commit 3e52d26fb7
25 changed files with 881 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Docs/Spec/Telemetry.md
+27
View File
@@ -178,3 +178,30 @@ does not.
settings pass, not before.
- **Q4. Typed payloads.** A JSON object per event is convenient and unsafe. A typed struct per event name is the
later answer if typos in payload keys start costing analysis time.
## What was built, and where it differs
Step 2, 2026-09-16.
- **Layout as specified.** `SaltyCore/Telemetry/` holds `TelemetryEvent.h` (event, envelope, the `FTelemetryPayload`
builder and the pure `Telemetry::ToJsonLine`), `TelemetrySink.h` (the interface and the three sinks) and
`TelemetryEvents.h` (the four session names; the catalogue grows with each emit call). `Salty/Core/` holds
`UTelemetrySubsystem`, `ASaltyGameMode`, `ASaltyGameState` and `SaltyCheats.cpp`.
- **The serialisation is one pure function** the sinks share, so the tests check the envelope without a sink.
The JSON Lines sink is an `FRunnable` draining an MPSC queue every two seconds and on `Flush`; `Emit` only
builds the line. Files are `Saved/Telemetry/session_<utc>_<8 hex>.jsonl`, the hex being a per-instance id so
two PIE instances started in the same second never share a file.
- **Sink choice:** `-telemetry` or `telemetry.File 1` wins everywhere, including the editor, so a PIE session
with a dedicated server writes one file per instance; the log sink is the editor default; null otherwise.
- **The session id** is minted in `ASaltyGameMode::InitGameState`, written to `ASaltyGameState::SessionId`
(replicated, `OnRep` adopts it) and begun on the server directly. `ATemplateGameMode` now derives from
`ASaltyGameMode` so the template Blueprint game mode mints a session until step 3 replaces it.
- **`MarkCheatUsed` takes an optional command name** and puts it in the `cheat_used` payload; the spec's
no-argument signature still works. `bs.TelemetryTest` is that call, so it emits and taints in one.
- **`player_id` is empty on every peer** until step 3 mints one on the player state; `party_size` is the game
state's player count and is zero at `session_started` because the join has not happened yet.
- **The build string** is `FApp::GetBuildVersion()` plus the git short hash read by `Salty.Build.cs` (D-42).
- **Proved:** four `Salty.Core.Telemetry.*` tests; a standalone `-telemetry` run wrote `app_started`,
`session_started`, `session_ended`; a headless `-server` and a `-game` client each wrote a file carrying the
same `session_id` with `is_server` true and false; `bs.TelemetryTest` wrote `cheat_used` and every later line
carried `cheats_used: true`.