Per discussion for #18 it's become clear that there's a need for mods to figure out what other mods are running. This allows DLL mods to adjust for the existence of other content (eg randomizer + big overhaul mod).
One way employed in the past was parsing the modengine2 config but with the introduction of the YAML format as a supported config format. That approach has grown in complexity quite a bit. To add to that, with me3 a so-called profileVersion has been introduced which should facilitate changes to the spec, which would make the task of detecting mods even more cumbersome.
Instead of mods all implementing their own means of mod discovery, a better approach would be for me3 to expose an API for this information that mods looking to do discovery can call. This way they are not tied to specific mod profile versions nor do they have to include YAML and TOML parsers as a dependency at all.
Per discussion for #18 it's become clear that there's a need for mods to figure out what other mods are running. This allows DLL mods to adjust for the existence of other content (eg randomizer + big overhaul mod).
One way employed in the past was parsing the modengine2 config but with the introduction of the YAML format as a supported config format. That approach has grown in complexity quite a bit. To add to that, with me3 a so-called profileVersion has been introduced which should facilitate changes to the spec, which would make the task of detecting mods even more cumbersome.
Instead of mods all implementing their own means of mod discovery, a better approach would be for me3 to expose an API for this information that mods looking to do discovery can call. This way they are not tied to specific mod profile versions nor do they have to include YAML and TOML parsers as a dependency at all.