Mod within a mod

I messaged @Wharp about this but I couldn’t wait for his response :stuck_out_tongue: He was also trying this sometime ago.
You can have a 2nd part mod that loads only when your main mod loads, like Rayya’s Children UI that only loads when you play with them.
The usual way is to have 2 mods. Wharp has tried (and actually got it working) to add the second mod inside the first one, so you can distribute a single mod file instead of two.
The problem is this only works for unpacked mods. Those packed into a .smod will not work as the file paths will fail.

Has anyone also tried this? Just wondering as it will be way better to have a single file instead of 2.
(Worst case I ship a zip containing both .smods)

1 Like

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”).

dependent mods will be placed into {stonehearth}/mods/parentmod/plugins/, instead of{stonehearth}/mods/
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…

Just do the “main mod” and have the second as an “expansion mod” or zip both .smods together and tell people to extract the contents to the mods foler.

The issue I ran int with mod within mods is that deferred load mods don’t work when they’re within a zip, so you can get a mod within a mod to work, kind of like how @sphr said, except it has to be uncompressed.

1 Like

That’s not really possible. AFAIK, the engine only loads the folder that’s named like the zip (because the zips are just a virtual filesystem of some kind). So while you can have multiple folders, you can’t access them.

If you are talking about pure lua, then yes, it’s possible to load things at runtime. However, everything that requires messing with overrides, mixintos and mixins won’t work, because there’s no way to modify them at runtime. While you can monkeypatch lua and Javascript and are even able to do some really nasty HTML/CSS tricks using JavaScript and commands, you can’t modify JSON. Technically, it doesn’t really matter if you define an entity as long as it’s not referenced anywhere, so merely adding content would work.

Anything that tries to modify content will need to be loaded through the modding interface.

So the short answer would be “Not really”, I suppose.

Unless that change since Alpha 14 or so, SH is just another mod with no fixed priority. It was possible to do stuff before/after SH by naming a mod in a way that it would appear before/after “stonehearth.smod” (e.g. “amod” and “zmod”).

1 Like

Reminder from last livestream: Thanks to Yang, we’ll have new tech that allows hotloading manifests as opposed to mods.
So hopefully we won’t have to worry about this problem :smile:
We’ll be able to have all the assets in the same mod, and enable the mixintos and overrides on the hotloaded manifest.


Uhm, I missed that. Which part of the stream? I will rewatch later.

It’s near the end. You’ll see the explanation if you start watching at the 1h 2min mark approx.


Wow, no wonder I lost it. The 1:02 to 1:05 is the exact time when I was away :rage:

And that is incredible!
Not only we will be able to hotload manifests, but there is also one specific manifest loading within biomes! That will simplify a lot of things to me.


I need it for Candyland too :smile:
I was so excited when I heard of it, but I wanted to wait for her to announce it publicly first before saying anything here on Discourse .


I just lost all my work flow now, too excited to concentrate! :smile:

I wonder what will be the priority, like exactly when those will load. (I hope as soon as we select it, exactly like kingdoms that activates as soon as you select them)
My main problem is that somethings are loaded too late and the game already has the wrong object in memory and ignores my new overrides. Which made me build a lot of “hacks” to load the correct things…