The initial implementation of DML ended up loading mods quite late,
which did give it the benefit of all `Manager`s being available.
This change therefore moves mod loading until after those are
initialized.
But contrary to old DML, we still create a separate game state to make
sure the game doesn't advance until mods are loaded. This avoids race
conditions like the one where LogMeIn needs to come early in the load
order.
Non-bundled mods come without a `dtmt.cfg`, and therefore without a
version number. But we need a version number at import to compare to
for the Nexus update check.
Non-bundled mods come without `dtmt.cfg` and therefore no way to
provide a user friendly name. Similar to the other fields, use the one
from Nexus in that case.
lint/clippy Checking for common mistakes and opportunities for code improvement
build/msvc Build for the target platform: msvc
build/linux Build for the target platform: linux
Libraries like `io`, `os` and `ffi` allow practically unrestricted
access to the system's files and running arbitrary operations.
The base game removes them for this reason, and while we don't want to
disable them permanently, very few mods should ever have a need for
them.
So we hide them behind a setting, worded so that people only enable it
when absolutely needed.
Closes#112.
This re-enables stdout/stderr logging for release binaries for DTMM.
As a GUI application, it usually won't be started from a CLI, and there
should be no negative impact from that.
But since stdout logging is synchronous and much faster than the async
action that writes to the log file, it might get to log more when the
application panics.
Usually the backup created by the first deployment is used for a clean
file to make further deployments from, but when the game is updated,
that is reversed, as now the original file is newer than the backup.
In such a case, we first copy the new file to our backup before
continuing with the deployment.
The current implementation is not fool-proof (e.g. it'll do weird stuff
if users mess with the files manually) and doesn't cover everything. But
it should be enough for the regular use case.
Closes#90.
Druid doesn't yet implement options necessary to create a "standard"
message dialog. So for now, we'll have to approximate that with what
we've got.
Fixes#70.
The log view itself still works correctly, as it is lensed onto the
field. But ignoring log from general Data comparisons prevents it
generating state changes.
This also removes the log for unknown commands. In practice, missing to
implement a command hasn't been an issue.
