List of mods (folder wiht more that one mod)

I think it would be helpfull in organizing things if in a folder we could have more than one mod.

For SoD mod for EG I have atm something like: (only an excrept)


So in listOfMods.json I would like to list mods 2-3 levels further like creatures or heroes.

(Maybe it is possible already…)

Something like this was discussed recently under name of “minimods”. See most of this thread: [

In short:

  • good idea, but not as simple as it looks like.
  • such tree-like structure may make our modding system code too complex.
  • proper handling of such structure by mod manager is not trivial.

If I understood mini-mods correctly than they are totally different from my list of mods idea.

The whole purpose for list of mods feature is ONLY at folder structure level. You have a list that tells you where the mods are. This list would allow users to use internally any folder structure they want that has no meaning to mods. (My SoD example from above exemplifies this)

Actually this listOfMods.json could be just an array inside mod.json.

As for code complexity… It should be as simple as this. Read mod.json, if no “listOfMods” is present proceed as usual, if there is one read mod.json for every entry in list. That should be trivial to implement.

That’s just a different approach for the same idea.

Folder structure is more like an implementation detail. My main problem is how to display such relationship in mod manager. Displaying them in plain list will give huge amount of mods while using tree view may result in weird behavior of sorting/filtering features.

And in case if this is not obvious - I’d like to remove any need for users (and maybe modders at some point) to open Mods/ directory ever and do all mod-related tasks via GUI.

For now I’d like to avoid any changes in that area. Re-iterating over such ideas is something I’d like to do later after current plans (mod manager and everything related to it) are mostly completed.

From what I understood the current solution to mods is to have all of them in the mods root folder. Interfaces mods are not there and then some others. If you have a separate root level mod for everything it will be a messy folder. You will end up with 3-5 folders for every new town for example.

I do not know how you thought to implement the GUI but to me it makes sense to have 1 entry called cove and this to have a number of submods. So why not go a step further and match this hierachy in the mods folder 1:1?

Whether this is represented in GUI as a 2-3 level tree or as a list with sorting options should not be that important. Personaly I imagine this as a max 3 level windows explorer like tree. With big stuff in root like: factions(or ])/interface/miscelaneous/etc.

Check my 1st post in that thread - there is link to first version of UI (not tree-like though).

Right now I’m not sure if I can make tree-like UI look “right”. If I (or someone else) will manage to do this - then tree-like structure for Mods/ will be possible. Expect some more discussions on this topic later.

I’m not against this feature I just think that it is too early to add it right now. This may change with time after engine will get some improvements.

Why? In interface mods most of data will be put under /Content/{Sprites, Data}. There won’t be 2nd subdirectory with mod name to properly replace files but that’s the only difference from new content mods.

What I meant with Interface mods was that they will most likely be numerous (at least from H5 experience) and will clutter a lot mod namespace. So it would make sense to put them under a common mods/interface/ folder.

One of the things why I started working on the SoD mod was that once that in place and working, will mean that modding is close to completion and will allow/facilitate/inspire others to start working on implementing all those functionalists that are not core H3 but VCMI needs badly. (Like lots of interface improvements!, new completely functional factions, translations into EN, some kind of patch/balance mod to account for…well all the imbalances).

And all of the above can be done by others with minimum developer intervention!!!

Perhaps filter by mod type may be a good idea for mod manager? Forcing modders to place interface mods differently may be the bes idea.

Far from it actually. I listed somewhere what’s still missing from HotA feature list. And this is mod that makes almost no changes in game apart from new town.

While I can implement such filesystem ASAP this is not necessary a good idea. With current state of mod handling this may lead to overcomplicated code that may cause multiple bugs (directly or indirectly).

WoG optionality is a good example - before 0.93 making wog optional most likely would have resulted in ugly barely working code that needs rewrite. While in 0.93 it was possible to implement it almost with 0 wog-specific changes.