Using os.path.getctime for the order, not the filename. This addresses the
changed Journal filenames in Odyssey Update 11, whilst keeping compatibility
with the Horizons Update 11 old-name-style filenames.
1. We need StarPos (as well as StarSystem)
2. Adding more state tracking in this plugin is misguided.
3. So added it in monitor instead, putting *copies* of data in the
monitor.state dictionary.
4. So we reference those, but only available in journal_entry() itself, else
we'd need to pass the whole of `state` in.
5. So instead pass in the bits of `state` only when we need them.
We can't just use `EDLogs.live` here as it'll get set `true` when the
`Commander` event is seen *during the catch up*. We need that catchup
to have finished before we'll try processing a `NavRoute` event and
file.
The order of Journal events changed from:
1. LoadGame
2. Rank
3. Progress
to:
1. Rank
2. Progress
3. LoadGame
in Odyssey, and in at least current 'base game' and Horizons clients as
well. Also 'Reputation' event is before 'LoadGame' now. So simply
allow those events to have populated the data, don't re-init on
LoadGame.
Yes, I'm preferring to leave the lines in, but commented, so it's clear
why those aren't being init'd, *and* why 'Statistics' still is, and as
of what game version.
The old code did this, and without it we enter a loop of:
1. CAPI says unauthorized
2. We call login()
3. But companion.session.state == STATE_OK, so do nothing
4. Re-scheduled CAPI request goes back to 1.
* Currently a maximum of 5 attempts, 10ms apart.
* I was going to blank `entry = {}` for this, but there's a chance the
file load would fail when at startup and Embark the in-Journal event
actually has all the data. So we cross our fingers and hope that's
the case if loading fails.
* Changed the "not all the categories" logging to WARN to call out the
failure.
* Removed old comment about not touching Backpack here.
This is mostly classes and mods for weapons, and classes for suits. I
did not do any updating passed what we already did, I simply added the
fields where needed.
This means that if our tracking is incorrect it will still be incorrect,
but full on tracking will wait for OO based state storage to prevent
whoopsies and other silliness.
These are the same as the ones on FileHeader, but it wont hurt to update
them here anyway, if they exist. Likely they wont have changed, but just
in case
* This is after rebase on `develop`, so some 'new' events needed
lowering.
* But there's one instance of entry_type being used as a key into
monitor.state, so will need to rework that.
