1. The updater is in a thread/DLL and we don't want that firing part way
through shutdown, so it gets asked to stop first.
2. Then plugins, so they're out of the way and we won't have already
stopped something they might rely on.
3. Hotkey after that to head off the user triggering something via them.
4. Now stop the programmatic input from Journal files (including
Status.json).
5. Frontier auth handling.
6. And then anything else.
Python's name-mangling rules are quite complex. Previously, EDMC was
incorrectly mangling names where the class name starts with one or more
underscores; if the class name starts with any underscores, they should
be removed before prepending to the identifier being mangled. If the
class name contains *only* underscores, no mangling should be performed.
monitor.thread should only be none when there's a <<JournalEvent>> to
process if we're in shutdown, in which case we do *not* want to be
processing journal events.
A user can collect multiple missions with the same mission cargo, which
is added to the cargo.json as distinct entries. Previously we would take
the last number as the total, leading to invalid counts (and possibly
negative counts).
This adds a method to sum cargo entries based on the cargo name. It also
adds a field on status to access the original cargo JSON data.
Fixes#817
This is some best effort support for using logging in properties.
This works by using the (as suggested by reporter) inspect
`getattr_static` method, and failing that (as it can possibly fail),
wrapping a `getattr` in a try/catch for a RecursionError--don't want to
catch other things, probably best if that explodes on its own.
From there as the `property` object will not have location information,
we rebuild as best we can to an approximation of what the path would be.
With a healthy dash of defensive programming "Just in case".
I don't think that this will have any adverse effects to other logging
methods, as all the new code should only be touched if we hit a property
object.
Closes#808
