Feature: modpacks

AVS · October 19, 2015, 10:07pm

Some initial ideas.
** New mod type: GAME aka modpack aka Master mod**

has no namespace (shares core namespace)
one and only one can be enabled at a time, launcher is responsible for this option validity.
can contain regular mod as submod
all H3 specific parts will go to separate regular mod (with optional separation of original expansions)
files like save games and possibly game settings must be stored separately for each master mod.
One normal mod may be present and enabled in master and regular at the same. This is not recommended, reported as warning but correctly handled by mod handler with priority of master mod part.

Macron1 · October 20, 2015, 7:41am

That is the consequence of moving modSettings.json to /Documents/My Games, i think.
I think it’s better to not make GAME mod (this will lead to thing that mod moved to GAME cannot be played in other GAME), but to think about returning modSettings.json to config folder back.
Than each copy of HMM3 + VCMI will be working as separate GAME again.
And make new json file for setupping games, in which will be pointed, what mods and what submods of mods must be used in GAME sets.

Like
}
[/code]

{
"default":
    {
          "name":"Default Game",
          "includedMods":
             "forge-mod","preserve-mod","hota:cove"
          ]
    },
"forgeWars":
    {
          "name":"Forge Wars",
          "includedMods":
             "forge08-mod","polish-forge-mod","superforge-mod"
          ]
}
    }
}

And On start select one of these sets.
Of cause some UI tool must be made to add mods to game sets.

Ivan · October 20, 2015, 9:00am

Good idea. Something like this should have been from the very start. Some thoughts:

master mod has own namespace, “core” is hardcoded name for H3 master mod. Reason: if a certain mod relies on existance of H3 object then it wont work with another master mod. So such mod must have master mod as dependency.
files like save games and possibly game settings must be stored separately for each master mod
if client starts with multiple master mods just show error and exit. Launcher is responsible for providing correct configuration for client and must ensure that there is always one active master mod.
as for pregame I’m not sure. Such conflicts can happen everywhere and not only in pregame. What if two mods want to change hero screen? Which mod should take priority? Problem is lack of well-defined concept of UI mod.

This also means that current “core” mod should stop being virtual and all h3 data should be moved to it (majority of configs) and h3 importer aka legacy data should be parsed only if heroes 3 mod is active. We also still have some hardcoded id’s (mostly town building but there are some arts and creatures as well. All of these should be rechecked and removed from code if possible.

AVS · October 20, 2015, 11:07am

Where to put “generic” map objects like “creatureGeneratorCommon” ,“creatureBank” (only type - subtype is part of Game)? I think we should retain some core part. As for Heroes objects, they should be part of SoD normal mod.

AVS · October 20, 2015, 11:11am

The idea of Game aka modpack is that you include forked version of “upstream” mods and tweak balance. Only solid modpack can be actulally balanced.

EDIT.
First port updated a bit.

Ivan · October 20, 2015, 12:15pm

Yeah it does makes sense to have some common library for common/hardcoded elements. Not sure if cregen is a good example though - creature generator object with id 17 is h3 specific.
Creature generator class that can be configured with creature id is generic part here (handler field in object type description). And IIRC those are not part of nod system.

I was mostly referring to current h3->vcmi converter that works with core mod as well. This part should me made conditional.

BTW - there is one more missing piece here - localization. There is no need for total conversions to use that weird h3 txt format with dependency on numeric indices. Imo this needs a proper solution, be it json based or something that works well with modern translation tools.

AVS · October 20, 2015, 12:44pm

Yeah, Bonus types is better example (they full mod support is next task)

Absolutely agreed about conditional. But it should not rely on core (or any other mod id) - only on indexes.

Smth like GNU Gettext over Json. Json contains English texts and support for H3 TXT files use. POT generated on json, localization handled by gettext.

val-gaav · October 20, 2015, 3:25pm

This would be very handy for me. I could just turn on legends turn off sod and distrubute legends pack with vcmi. Updating game to newest vcmi would also be easy just put my mod files into mod directory no need to edit/replace SoD configs… or those could just be deleted.

So to sum up great idea

However it seems a lot of work. I recently peeked at json vcmi config and it seems most of the stuff is configured from txts in lod. I also edited those json configs to remove tower and failed Game just crashed at start while I’m pretty sure I removed all tower strings in json configs.

Having configurable grail effects and other special in game buildings would also be very nice and needed

One question though what about maps ? I guess only the new json map format would be supported with those GAME packs ? Each game pack would have it’s own map format ?

AVS · October 20, 2015, 4:32pm

Yes, h3m maps will not work without SoD/ WoG mod (but regardless of master mod). But there is a trick: if f.e. your - Legends - mod will define object with same Indexes it may not difficult to make original maps work also with legends, however this is a dirty hack…
Map depends on set of mods but not modpack itself. Map can played if (obviously) all required mods are present. Only if you make map depend on master mod itself it will not be playable without it.

Ivan · October 20, 2015, 4:39pm

Something like that, yeah. Although this won’t help much with images localization (e.g. main menu) and may be tricky in our case - gettext usage assumes that there is some sort of “default language” which is used as base text for translations and for detecting changes. But in H3 community Russian and Polish are used more often than English. Some sort of stringtable may be more applicable to vcmi ( “st_mainmenu_newgame” -> “New Game”) however I don’t know how easy to use such approach would be for translators.

True although I’d rather have mods in our repository instead of mods redistributing own vcmi version.

Such use case was never tested so yeah - that is the expected result unfortuntely.

Good news is that VCMI can read data from JSON ignoring h3 txt’s (it still will load all of them however data in json has higher priority) and it is possible via mods to remove objects from base game ( “pikeman” : null will remove pikeman from the game but this will cause crash on pretty much any h3 map ). Don’t think that such approach would work with towns - for example town selector in map options may not check for town presence and such.

Wrong. Having configurable buildings would be very nice. And the more I look into configurable the more I convinced that the only realistic way for that is through scripting.

krs · October 20, 2015, 4:51pm

… dusting off my 2 year old post: SoD as Mod

Main idea was to have SoD completely as a mod. To implemented there was a need for mod/submod support from VCMI

It looked like this:

<vcmi data dir>/
   Mods/
      sod/
         mod.json
         Resources/ (if needed)
         Overrides/ (if needed)
         Mods/ (sod direct submods)
            factions/
               mod.json
               Resources/ (if needed)
               Overrides/ (if needed)
               Mods/ (submods of Factions mod - H3 towns)
                  castle/
                     mod.json
                     ...
                  rampart/
                     mod.json
                     ...
                  ...\code]

And this is the actual implementation without the resource files copied over.
http://pastebin.com/ecHbVCbX

@Ivan is all that still valid? Any changes?

Ivan · October 20, 2015, 5:34pm

We have basic submods support for like two years already. Now main problem is separating data in multiple mods (should be doable without coding) & removing remaining hardcoded bits.

However due to these hardcoded bits disabling most of H3 content is still not possible so while you can split h3 data in multiple mods you still won’t be able to disable them.

That’s pretty much all I can sasy without actually trying to do this. I won’t surprise if you’ll run into some issues that were not detected before

krs · October 20, 2015, 6:49pm

If this feature is wanted, I can update and the upload the files I have.

I can take 100% the resource moving and the .json restructuring (I have 70% already since my last try with Ivan 2 years ago). But! code changes will be necessary and I will not be able to do them. So if anyone is up for the task…

And it has to be done in parallel, otherwise it will be a nightmare to keep splitted .jsons up to date.

And it has to be done incrementally (faction, followed by spells, artifacts… otherwise it is a little too much a change from 1 chunk)

AVS · October 20, 2015, 7:02pm

I will help with code changes, but don`t expect me to lead this task.