Submods support and other changes in mod system

Hi. I’m going to commit second part of submods support tomorrow that will bring support of submods to launcher.

Now VCMI will read mods not only from /Mods directory but also from all Mods directory of each mod. So each mod may have following structure:

            <mod structure>
            <mod structure>


  • Submods can use archives simiar to normal mods (e.g. but submods themselves (e.g. submod directory or mod.json) can not be in archive.
  • Submods are handled recursively so it is possible to have submods in submod and so on.
  • for places where VCMI needs mod ID submods can be referred to as .
  • submods will be loaded only if parent mod is present and enabled

Known issues:

  • If parent mod is disabled launcher may display submods as enabled.
  • [FIXED] Launcher can’t handle submods in repository yet.
  • [FIXED] Launcher ignores submods of inactive mods.
  • There is weird update delay in toggling submods on and off. Bug is only visual - launcher applies changes in settings immediately. (for some reason model does not sends correct signals to view)
  • [FIXED] (unrelated note to myself) Launcher still prefers using data from repo to local data. Reported in Tarnum mod thread.

Changes that I’d like to make with current mods in repository:

  • Localizations (mostly Russian so far): will be turned in submods.
  • VCMI “mod”: should get language-specific submods as easy way to indicate desired translations.
  • Cove: will be reorganized into set of submods with parent mod named “HotA”.
  • High resolutions pack: I’d like to split it from the rest of package. If needed, it may remain part of release package but I’d like to get rid of current “” package and keep all files which are necessary for vcmi in repository
  • True type fonts: I’m considering merging this mod into repository and turning it into disabled by default config option. Reasoning: current bitmap fonts don’t work well with unicode since they provide only language-specific character set.
    Of course, only changes that do not break 0.95 compatibility will get into repo for now so this is more-less my plans for next release.

Planned changes in mod format:

  • boolean field “keepDisabled” that wil control whether (sub-)mod will be enabled on install. I prefer such wording to something like “keepEnabled” is that in this way we’ll keep current auto-enabling behavior (default value for bool is false).
  • field “license” - indicates license of mod. Exact format of this field is either:
    • string that indicates license (recommended CC-BY-SA 4.0).
    • struct that consists from 2 items: “name” (e.g. “CC-BY-SA-4.0”) and “url” that will point to license (either link to file in repo or to some other location of license)
  • object field “changelog” - object that consists from entries “version” : “list of changes”
  • list field “screenshots” that will contain list of screenshots for this mod. Screenshots should be uploaded to instead of hosting them externally to avoid dead links.

Example of changes:

"keepDisabled" : false,
"license" : "CC-BY-SA-4.0",
"changelog" : {
    "1.0" : " a lot of stuff",
    "1.0.1" : " a lot of stuff",
    "1.1" : " a lot of stuff",
    "1.2" : " a lot of stuff"
"screenshots" :  "", "" ]

Note on mod licenses:
I think that we should decide on license that will be used for all mods that do NOT contain H3 data. CC-BY-SA looks like a good choice since this is closest one to GPL which we use for code. URL:
I’m going to contact mod authors if they’re OK with this license but I don’t expect any problems since these are more-less terms that were used by most of HoMM community for quite a while.

This also includes assets that are required for VCMI to run properly - stuff like creature window and quest window should be replaced with “free” assets and uploaded to trunk (I want to finally get rid of issues that come from missing data package)

Am I right, that there will be possibility to make for example 5 submods, that will be interchangeable? Like I place submod with English text, than with Russian text, etc, than choose only one to load in launcher?
So I can make 10 submods with different HMM3 skins/menus and choose between them?

Submods behave exactly same was as normal mods so probably yes. This is how launcher looks right now (still needs some improvements though). … uncher.png

Nice work :slight_smile:

BTW. Will fields like ‘licence’ etc. be obligatory?

Maybe in the future there will be an option do add some screenshots as well, though I do not know how will it influence data transfer if there are a lot of mods… seperate button perhaps to view them?

I’d like to have license mandatory but realistically this is not possible since some of mods modify H3 files. So all of these fields will be optional. “changelog” and “license” fields are likely to have some kind of recommended status but it won’t be enforced by things like mod validation.

Good idea. I’ll add it to my first post here.

Probably will turn right part of mod view into tabbed with at least 3 sections:

  • Mod Info tab: what we have there now, mod information generated from mod.json
  • Screenshots: list of thumbnails with some way to open them in full size.
  • Changelog: since changelogs can quickly grow big enough so they won’t fit into mod info

code committed to SVN, still needs some work but should not have any major issues.

All new fields are implemented and I’m done with new features for Launcher for now. Although this does not includes bugfixing and removing some limitations (like submods that can only be installed with parent mod).

And update on licenses - I got permission to use CC BY-SA 4.0 for following mods:
Centamoths (Axolotl)
Cove (HotA Crew)
High Resolution Menu (Dru).

Judging from number of changes to mod format I’m thinking about creating some temporary repo with all changes I’d like to make in mods. Or maybe even creating separate repository for next version and copying all mods that don’t need changes into it. Probably will focus on this in April.