Repository navigation
Sync: opt-in live fleet state ("fleet" records, config key "fleets") - #325
ProgenyAlpha wants to merge 2 commits into
Conversation
|
Tested in-game on Windows (build from this branch, |
Subscribe to fleet_watch from the sync patches when any target enables
`fleets`, and queue one record per FleetState transition:
{"type":"fleet","fid":<fleet id>,"slot":<0-9>,"hull_id":<hull or 0>,
"level":<ship level>,"state":<FleetState>,"state_name":"Mining",
"prev_state":<FleetState>,"t":<unix seconds>}
A full snapshot of all occupied slots is queued as a first sync
(X-PRIME-SYNC: 2) whenever fleet_watch establishes a baseline (login,
fleet topology change) and whenever another category's first sync is
queued. Callbacks run on the game thread and only build JSON and queue
it; HTTP stays on the existing sync worker.
fleet_watch gains an optional Subscription::on_baseline callback.
Default off; documented in every example config.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DNMkDr9v6waKrZ538gutCK
HullSpec::Id is read as a 32-bit long and hull ids exceed 2^31 (Kumari is 3005922948), so widening the signed value put negative ids in the records and name lookups failed for those hulls. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNMkDr9v6waKrZ538gutCK
bc3508e to
8aa63dc
Compare
|
Rebased onto |
| {"state", static_cast<int>(state)}, | ||
| {"state_name", state_name(state)}, | ||
| {"prev_state", static_cast<int>(previous)}, |
There was a problem hiding this comment.
To be consistent, shouldn't we include prev_state_name too?
3 participants
What
Adds an opt-in sync category that posts live fleet state, built on the existing
fleet_watchobserver.SyncConfig::Type::Fleets: record typefleet, config keyfleets, default off. Added to all example configs (validate-example-configs passes).fleet_watch: an optionalon_baselinecallback, fired on the game thread when the observer settles on a stable view of the slots (after login and after any slot occupancy change).sync.cc: when any target enablesfleets, a subscriber queues one record per state transition:{"type":"fleet","fid":..,"slot":0-9,"hull_id":<hull id or 0>,"level":..,"state":<FleetState>,"state_name":"Mining","prev_state":<int>,"t":<unix s>}and a full snapshot of every occupied slot, flagged as a first sync, when the baseline settles and whenever another category's first sync is queued. Callbacks only read fleet properties and push JSON on the existing queue; HTTP stays on the sync worker. No fast polling is requested, so slots are checked on the observer's normal rotation.
Why
The sync feature covers what the server reports (ships owned, jobs, research, ...) but nothing about what fleets are doing. A local receiver can now show "which miners are mining" without any third-party service.
Status
🤖 Generated with Claude Code
https://claude.ai/code/session_01DNMkDr9v6waKrZ538gutCK