Required features:
IMO this should be not just “mod manager” but rather “vcmi launcher” to cover not only mods but such fields like pre-start game configuration (options from settings.json that can’t be changed in-game like AI and server port).
For mods this should also offer centralized repository to enable installing/updating for mods.
Repository:
Repo will be maintained manually at least at start - json file acting as index + URL’s to mod packages. Each entry in index will use same format as mod.json but without filesystem-related entries. Mod.json will also need some new entries lke version - check this page: wiki.vcmi.eu/index.php?title=Use … format_WIP
Mod packages:
For packages I think we should use compressed .zip archives with such structure
archive.zip/
modName/
mod.json
content.zip
archive.zip is highly compressed file, unpacked on install
modName directory is needed so mod name won’t be lost on renaming archive
content.zip is current “content” directory package in zip without compression. This should give a bit faster access - no files scattered around hard drive and no compression to spend 90% of time in it.
Right panel is normally hidden, with mod list covering whole window, can be activated by double-clicking any mod to show more details about selection
Filtering - either by wildcard (search goes through all fields, not only name) or by mod type (all, installed, enabled, etc)
Nice idea. Launcher is something we definitely need. In the future it would be good to integrate setting up multiplayer games in it.
Regarding the interface: the only change I’d suggest is to turn mod list into QTreeView/QTreeWidget. Normal list is good when you just want a mod or don’t want it (full WoG or no WoG). If my suggestion of mini-mods is accepted, a tree structure will allow flexible turning on and off both whole mods and just their parts.
I certainly like minimods idea. But I thought that this is more like “small mod that depends on big one” rather than some kind of “submod that is part of another mod” - IMO tree structure for mods will overcomplicate our mod system.
I think that we should keep mod structure (Mods directory & modHander code) as a plain list and use tree structure only in mod manager (and detect such minimods by some extra field in mod.json).
So what interface for minimods do you suggest? Plain list with everything that flickers in random places when you select something is even more complicated than a tree.
EDIT:
Yes, I was describing mods that depend on other mods and it would be depicted by that tree – mods that depend on nothing, then as childten mods that depend on them etc. No mod-as-part-of-other-mod. I was even thinking about depicting it as a DAG of depenencies but that would certainly be too complicated.
But each of these submods have one extra field in mod.json, e.g. “parent” : “wog” or “minimod” : true (in this case first required mod will act as parent)
Mod manager loads all mods, detects these fields and generates tree structure from it:
As result mod handler will work without any changes (implementing tree structure here may not be trivial) and mod manager has nice tree-like structure.
Actually the idea of minimods wasn’t described at this level of details before… actually I wrote that proposal without really thinking about mod-minimod relations.
In the original idea I was thinking about a set of WoG-related mini-mods (there is no formal distinction between mod and minimod) and a full-WoG mod that depends on all of these minimods. Therefore installation of full WoG depends on istallation of all of its components but you can have just a few parts of it.
I don’t say it’s the best solution. It’s definitely incompatible with my tree-structure suggestion. Parent field actually makes sense to me.
The problem of GUI for child-mods remains. I don’t like mixing parent-mods and child-mods on one list. Where would you put on/off options for wog-commanders, wog-stackexp, etc.?
What’s a problem here? Swap 1st and 2nd columns in my mock-up and you’ll get:
1st column with name and expandable tree controls
2nd column with clickable icons to enable\disable mod.
I have to agree with this - it will completely mess up filtering and sorting which I think are essential functions here.
Perhaps go back to plain list and add submod list on right side (list with checkboxes below mod description).
Although in this case it won’t be possible to display any submod information apart from name.
Good job, Ivan! The launcher looks nice and simple to use. I think a plain list is enough, keep it simple! If the user wants to install/enable a mod with dependencies a list of mods to install or/and to enable should be shown. This should be enough. The user can search mods quickly by type or by name with wildcards and so on. That’s more essential, than a structured tree I think.
Perhaps I’m bad at explaining too. You’ve answered my first question in the second answer. And, as you note, your solution is quite limiting.
Tree/second list is essential for “I just want a part of this mod enabled” problem. And I think we agree that it’s a problem that should be addressed.
Mods can have “conflicts with” annotations that should be handled by launcher. This can address the problem to some extent. In-depth analysis of mods doesn’t even have to be desirable (overriding mechanism can be used).
Perhaps don’t add any UI for these minimods and instead add line into mod description similar to dependencies, e.g.
Note the underline - I’m using QTextBrowser here which supports hyperlinks so it is also possible to make all these items clickable.
May not be perfect but at least this solution is not as limiting as others.
No - I’d rather eliminate possibility of conflicting mods for example by namespacing all objects added by mods, keeping all new files in own “namespace” - subdirectory.
Apart from editing H3 data there is no need for two mods to alter same files. And even that area is partially covered by vcmi.
I think zipping mods is a very bad idea.
Now I can step by step change mod files, correcting parameters and running VCMI to look, what have changed. I can move files and creatures between mods.
I can correct picture in DEF editor and quickly build corrected DEF.
It will be Hell if I each action must do with zipping/unzipping.
Leave current mod structure as it is.
For example it took me 3 days to convert mods to 0.92b format and briefly check them.
Additional changes will additionally slow process.
And increase difficulty of modding.
I don’t think there is a need to change mod formats for this manager…
Zip’s are mostly for distribution - keeping current directory alongside with .zip is not a problem. For distribution zip’s offer several quite significant advantages:
one file instead of hundreds files on hard drive - much faster access speed.
possibility to check if mod was modified after last start. This will allow to implement “lazy validation” - validate only data that has changed instead of checking everything.
And you won’t believe but this was actually requested by modders some time ago. Check Era mods - all of them use .lod archive to store data.
Tow dragon, but none of these are usable with huge lists of items - no sorting or filtering. In one case (Mandriva package manager) there is well-defined grouping of packages which is not possible for mods, another one (Visual Studio installer) will only work with small number of items.
I think that I’ll keep simple list for now - Qt models are flexible enough to allow switch to tree without rewriting anything.
No it won’t. Technically current “Content” directory is not something completely hardcoded but rather default value for “filesystem” entry in mods which looks like this:
You can not only sort and filter but also group and limit such trees. BTW, you can look at Wireshark’s interface too. Not quite QTreeView but an interesting solution anyway.
OK. Therefore I’d advise to not care about minimods for now at all.
Moved zip discussion into separate topic. Ivan
[forum.vcmi.eu/t/zip-format-for-mods/661/1)
I believe it would be nice to add field “contact” or “adress” to mod, so people would know who to contact directly if mod doesn’t work or needs update etc…
What to expect in 0.94 in modding system?
Will there be another radical changes in modding system for creatures/towns/artifacts like it was in 0.93, or its only about mod.json and mod manager?
