Starfield adds a new type of plugin that I'm calling an override plugin,
which does not use up a load order slot when active, and a plugin cannot
be light and override at the same time. It also increases the BA2
version number, though the differences are not relevant to libloot's
usage, and loads BA2s from plugins differently.
The latest libloadorder distinguishes between plugins that are
implicitly active (i.e. they're active despite not being listed in
plugins.txt) and those that are made to load in certain positions by the
game.
The Microsoft Store installs Fallout 4 DLC to separate directories
outside of the game's install path. The relative paths are fixed: users
cannot customise the install paths (aside from the folder within which
all games are installed on a drive), and renaming the DLC's path or its
Content directory causes an error when trying to launch the game.
The game scans these additional data paths similarly to how it scans
the main data path: it doesn't only load the DLC plugins from their
data paths, it will find non-DLC plugins in them, and DLC plugins can be
moved between them and still be detected. The same is true for BA2
files and other resources.
To support these separate directories:
- GameInterface::IsValidPlugin, GameInterface::LoadPlugins
and GameInterface::SortPlugins() now take plugin paths instead of
plugin filenames. Relative paths are interpreted as relative to the
data path, so the change is backwards-compatible, and absolute paths
are used as given.
- LoadPlugins now checks that all filenames in the given paths are
unique, which was previously required but not enforced.
- When scanning for archives, LOOT now scans the DLC data paths before
scanning the game data path.
- libloadorder and loot-condition-interpreter have been updated to
support the MS Store Fallout 4 DLC paths. libloadorder has built-in
support for the Fallout 4 DLCs specifically, so does not need to be
initialised, while loot-condition-interpreter's support is not
specific and so it's now passed a list of data paths that includes the
Fallout 4 DLC paths when appropriate.
When listing the DLC paths together with the game's main data path, the
order they're listed in matches the order in which the game scans them
for plugins, with the game stopping at the first directory in which it
finds a file it's looking for.
This introduces detection of whether or not a game install comes from
the Microsoft Store: like LOOT and libloadorder, libloot detects this by
looking for an appxmanifest.xml file in the install path.
The new Game::SetAdditionalDataPaths() method may be added to
GameInterface in the future: that hasn't been done yet because adding it
will break the ABI.
If a group edge exists due to the presence of some user metadata,
distinguish that from when the edge exists only due to masterlist
metadata.
The logic for detecting when a path between two groups involves user
metadata gives results that are stable but that do not consistently
paths that only consist of masterlist metadata. If there are multiple
paths between two groups and some involve user metadata, the same path
will be picked every time, but the path picked depends on the structure
of the groups graph.
In practice this shouldn't be much of a problem because the paths are
only exposed when there's a cycle, and in that case all paths between
the two groups need to be removed/broken anyway.
The use of FormIDs doesn't apply to Morrowind and it's really the
records that are significant - FormIDs are an implementation detail.
This also aligns with other use of records in names.
Oliver Hamlet
Oliver Hamlet