When a vertex is unfinishable during a groups graph DFS, that means all the plugins in the path leading up to it are also unfinishable, and the comment I'd written in the code acknowledged that but the impl didn't.
The old approach made sense once, when the load order was the current load order and not the order that the plugins are given in, but that was a long time ago.
The mutex in the game cache wasn't very effective, instead move the
mutex out to the only place that concurrently writes to the cache.
This does mean that there isn't protection against calling
GameInterface::LoadPlugins() concurrently from multiple threads, but
no effort has been made to make libloot's public API thread-safe anyway.
- 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.
Oliver Hamlet