Consider a synthetic `LastSeen` event for plugins
- Dominant language
- Python
- Stars
- 1.3k
- Forks
- 182
- Avg merge
- 1m
- Merged PRs (30d)
- 1
Description
Currently after the latest Journal is loaded there is a synthetic `StartUp` event created, which plugins will receive, **but only if the game was detected as running during catchup**.
Assuming the latest Journal had an actual game login the main UI will show at least the Cmdr name, but unless the game was running this won't be passed to plugins. Plugins would need to wait for the game to be running (a necessary pre-condition for any new Journal events to be written, be it to the same file or a new one) to even know the Cmdr name.
So, perhaps in the "game was *not* running during catch up" case we should emit a new synthetic event, e.g. `LastSeen` (name up for debate), to pass that data.
Why not just emit `StartUp` anyway? Because the semantics of a plugin's `journal_entry()` being called is very much "this is new *live* data", and the current `StartUp` event matches that. If we're going to call the function with historic state/data, then it needs to be a new event so as to make that clear.
Contributor guide
Research direction
Start by tracing the Journal catch-up flow and the plugin journal_entry() calls, especially how the synthetic StartUp event is handled when the game is running. Define the historic-state event semantics and emit it when the game was not running during catch-up, then verify that plugins receive the latest Cmdr data without treating it as new live data.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100