Throw std::runtime_error for all esplugin errors except ESP_ERROR_PLUGIN_METADATA_NOT_FOUND, which causes a PluginNotLoadedError to be thrown, since LOOT needs to be able to distinguish that error.
- Don't clear the cache in LoadPlugins()
- Don't load plugins in SortPlugins(), and make it take a vector of strings, not paths.
- Add a ClearLoadedPlugins() method to clear the loaded plugins cache.
- Remove IdentifyMainMasterFile()
Instead of calling IdentifyMainMasterFile(), callers can use LoadPlugins() to initially load all plugin headers only, then omit the main master file when calling LoadPlugins() to fully load plugins.
Most of the complexity is handled by libloadorder, but it's worth noting that:
- The game path is OpenMW's install path, not Morrowind's
- OpenMW doesn't force master-flagged plugins to load before others
- OpenMW doesn't provide a way to record the load order of inactive plugins
- .omwgame and .omwaddon plugins are equivalent to .esm and .esp respectively, while .omwscripts plugins have a completely different format with none of the metadata that libloot uses.
- OpenMW effectively relies on additional data paths to load Morrowind's (and mods') files, and the last directory listed that contains a given filename is used to load a file with that filename, with the main data path effectively being the first listed.
- I've disabled support for ghosted plugins for OpenMW because it makes the multi-path stuff more confusing and may not provide any benefit.
The new logic is conceptually simpler, with fewer special cases to
handle. Unlike the old implementation, the new approach avoids cycles.
It basically does depth-first searches through the group graph, adding
edges from each group's plugins to the plugins in the group's
successors.
This involved reversing the direction of edges in the group graph, as
this switches the logic from trying to find predecessors to trying to
successors: the new direction matches that of plugin graph edges, so
it's less confusing.
I can't think of a situation in which the iteration order of plugins
within a group matters. I tested it manually with my test load order of
~1600 plugins, and saw no difference when the order was randomly
shuffled. I've added a test case but it's a relatively simple scenario
and there may be a more complex scenario where it would matter that I
haven't thought of.
A buffer is used to hold the plugins in the previous groups in the
current path, because that's noticeably faster than just recording the
path and looking up the plugins for each group in the path. It does
duplicate the group vectors, but that's an insignificant amount of
memory used.
The new approach has a negative performance impact, with sorting now 15%
slower than before.
A more efficient solution could be to implement a custom DFS algorithm
that doesn't stop when it reaches a vertex it's already visited (which
would be fine since the graph has already been validated to be acyclic),
as then only the root vertices would need to be searched from.
Oliver Hamlet
Oliver HamletandOliver Hamlet