From what I know (correct me if I am wrong), aside from the non-controllable load order (prob with exception of hardcoded ones like stonehearth.smod), mods are basically independent. They will be processed according to their manifest in arbitrary order since they won’t know each other’s status.
So if we want a “dependent” thingy, it has to be in one “mod”, which has to be in one smod or a folder. but since smods are basically packed, it is not in a convenient state to combine stuff.
some “casual rambling”
What I would try if I were to do it myself is to first make a parent mod, as a folder based mod.
Inside this parent mod, I would set aside some rules for “plugins”, or dependent mods. The dependent mods can be structured in a way that is common to all other stonehearth mods, with manifest “as if” it was in the main mods folder (so it CAN be loaded independently if it is placed “outside”).
i.e.
dependent mods will be placed into {stonehearth}/mods/parentmod/plugins/
, instead of{stonehearth}/mods/
i.e.
childmod
will be placed in a folder {stonehearth}/mods/parentmod/plugins/childmod
(instead of{stonehearth}/mods/childmod
)
Then, I will write a script (my current favorite is nodejs), that will go through all subfolders in the plugins folder and look for the manifest. I will then combined it with a “intended manifest” of the parent mods (which should contain what the parentmod’s manifest should contain if it does not have any dependent mods, but in a different named file so that it will not be overwritten), taking care to translate all filepath references in the plugin mod’s manifest to include the “parentmod/plugins” prefix, then write ALL of that into a generated manifest for the parentmod. I could even order the child mods if there are some metadata kept in another file packed with the child mods.
Though a little troublesome (need to run script to bake them into one), there are some niceties:
-
the child mods also be used directly in the main mods folder, or placed into any other mod which supports this “plugin framework”.
-
“uninstalling” a child mod can be either done by physically remove child mod from plugins folder, then run the manifest generation script again, or add some sort of exclusion file that the manifest generation script will read when re-baking the stuff to selective exclude childmods (so the source files can stay, but the contents of its manifest will be excluded)
-
this framework can be used … recursively. only thing is a child mod which uses the same system to contain its child mods will have to bake its manifest first, before it is baked again into the parent mod’s manifest.
Of course, this is just a rough plan. I am not familiar with the manifest system to know if the filepath translation will run into any game engine limitations when they read the manifest file (of the parent mod).
hmm… I think too much…