I think that if/when scripting is implemented this will become impossible to do. This would generally be equivalent to the halting problem and is not solvable.
I mean analyzing if a script creates the same creature as a different mod.
If the game does not let the user load two mods that change the same asset then mods of mods become impossible. For example changing a single piece of a whole skin mod.
That would be definitely a wrong approach, because it’s normal to combine mods by overlapping them. Many items usually overlap and it’s ok. For instance, HoL + New Interface, Phoenix + New Music Pack + Fast Battle Animation. Per-file system would create a complete mess. Today old music is played, tomorrow - the new one (dates changed) with the same set of mods.
In popular games alphabetical order of packages defines the order of overlapping (a.pak, aa.pak, b.pak). We decided to use list of mods in ini for that purpose.
Will there be an interface to this or do you mean for mod creators?
There are two different things: allowing users to choose the mods they want to use and allowing mod authors to set dependencies and loading order for dependencies.
The first needs an interface, the second is great with an ini-file.
EDIT: an example from a mod-author’s point of view.
Mod A adds a new town and skins the user interface. Mod B adds new neutral creatures and also skins the interface.
I want to create a mod using both the town and the creatures. I also add new music and a campaign. I like the skin from mod A.
So I make my ini-file with the list: A, B.
This means that the files from A override the files from B.
The user can select to load my mod C and another mod D that skins the interface. They load the mods D, C in that order. This means that the mods D, C, A, B are loaded.
Ini-file defines active mods and their loading order. Example:
It means that all other mods in the folder are inactive. Launchers/shells can specify path to other mod list to load instead of current, ex. “h3era.exe ModsList=MyFavorite.txt”.
This allows to distribute tons of mods in one folder and playable presets of them for ordinary players.
What concerns versions of mods and dependences, I treat them as sophisticated elements making the whole system overcomplicated and dead from the start unless you have huge community of developers like Linux has.
Why is the ini file ever needed? VCMI uses no ini file at atll and works fine. We can use already existing json files and add ordered list to the list of active mods.
Or better, we can just use ordered list instead of uniform collection of active mods, so they just will be added in specific order. This way we can control mod loading without a single change in code.
All that is needed is interface which allows mods to be reordered. But this can be done at any time.
In json vs ini I was just going with what Berserker wrote above, the syntax doesn’t really matter anyway.
I understood that the mods were meant to be ordered in Berserker’s post above.
I didn’t realize this had already been implemented, great work! perhaps it would be a good idea to make a simple example mod for testing and showing the json file. I agree the interface is not so important right now.
P.S. I am having a hard time finding the parts in the code that load and parse the config files, for example for creatures. Could you give me a pointer to that code?
You mean creature with same ID? In this case conflict can be avoided by prefixing all objects added by mod with mod name.
This still won’t solve all possible mod conflicts issues. IMO explicitly marking mod A as incompatible with mod B similar to dependencies is much more easier to implement.
The only thing that was implemented right now is filesystem. So it is possible for one resource to override another with same name but from different source. Check config/filesystem.json - it contains list of sources of original data files along with override priority. Mods can be added in the same way.
The thread is so long and ideas where changed and changed again. I had some trouble finding what is the latest stand. So please excuse if I am beating on a dead horse.
I am talking only about an interface for mods not about actual mod implementation. (or very little).
I was playing a DotA like game called Heroes of Newerth. It had one of the best, yet simple moding systems and I think it would be nice on VCMI. It was a small application that visually allowed you to enable/disable mods. If you wanted you ran it before the game started (Similar to Heroes 3 HD)
** Features:**
Graphically Enable disable mods
Distinguish between incompatible mods
Automatic mod update. (mediafire)
Provide general mod description, author name, link to website
Archived contents in 1 file for easy distribution / manipulation.
Each mod was zipped and at minimum it had 3 components.
An icon file (to display in manager)
A configuration / ini file to specify some general stuff. See below.
Folders with files for that mod.
<modification
application="VCMI" fixed
appversion="0.92" game version requirement ()
name="The Mod's Name" it will identify the mod.
modversion="1.0" The current version of the mod. Should grow with each new release.
description="Short mod description" Explanatory text about the mod to be shown when selected in the Mod Manager (optional)
author="mod author" Will be shown below the mod's name. (optional)
weblink="http://www.com/" A clickable link to be shown below the description text. (optional)
updatecheckurl="http://.../version.txt"A URL to a text file containing the newest version number. (optional)
updatedownloadurl="http://.../modname.mod"A URL to a mod file that will be downloaded and replace this mod file when the text file specified above contains a higher version number than this mod currently has. (optional)
>
<!-- Of the elements being described below each kind may appear any number of times and in any order -->
<incompatibility name="Other mod name" version="1.0-1.4" />
<!-- States an incompatibility with certain versions of another mod to be abided by the Mod Manager; this mod cannot be enabled when the other mod is enabled. -->
<requirement name="Other mod" version="2.5.1-*" />
<!-- States a dependence on another mod to be abided by the Mod Manager; this mod cannot be enabled when the other mod is not present and enabled. -->
<mod priority> Respective's mod priority. Use 10 increments.
</modification>
I ran into some maps lately that required some copying into data files. Not so hard to install but very hard to remove. And I had different maps using same system files…
Treat some maps similar to regular mods. This way they are easy to install uninstall.
Use map sub-folders. Will add some structure to map folder and will reduce header load times.
Zip maps. Maps come zipped from the net, because they have additional files. So reading from zip should be supported at some point. (regardless of compression advantages disadvantages).
Map Screenshots could be supported… (Or mini-maps I do not know the name, like the ones on websites.)
I think Era have something like that. If I am right - can somebody post screenshot or describe its functionality?
krs, have you played such games like Battle for Wesnoth or OpenTTD? They have really good mod managers (BfW especially)
XML? Json is definitely better…
Some of this data (name/description)is already here: wiki.vcmi.eu/index.php?title=Modding_guidelines
Fields like authors or mod site URL should be added there as well.
Requirements\incompatibilities will be part of mod config too but this needs implementation.
As for downloading - central repository (like in games I mentioned or in most Linux distros) would be much more better - full list of mods (including not installed), dependency resolution, ease of updates.
Right now you can install mods with one map in it - quite close to what you’re proposing.
This is planned for mods in general. Compression will definitely kill performance but for distribution or to store all data uncompressed in one file (faster disk access) zip’s will work.
Man you picked that up :). The place where I copied that from uses XML. Of course here you will use json. I copied it for the structure. It has all fields that are necessary for a mod.
I brought in this example because it was simple and easy to use. I tried wesnoth but did not like it so no idea about mods there. I know Curse from WoW but that one is overkill… the idea was to have it graphically and to have autoupdate and the ability to manually specify inconsistencies. The exact implementation is of little importance to end user.
Of course I did
But seriously - on my screen this looks like unreadable pile of text. My screen is not wide enought I suppose.
Base system is usually identical - some description, disabling\enabling, dependencies support. However relatively few systems support updating, even less - central repository where player can take a look on available mods, auto-install dependencies.
Here some screenshots on how this looks in BfW: shadowm.rewound.net/blog/archive … .11.0.html
I have to say that I dislike the BfW one. Here my thoughs about it.
I like the filter option. You will see only what you want. For example only enabled mods.
I like that is available in-game. Although it can be external also and I wouldn’t mind.
It is easier and more meaningful to browse mods on a website and pick from there what you want. You can have there more information available about each mod. You will not cluttered your mod manager with mods and information that you do not need. (For example i do not care about size and download count information for my 15 mods I have).
2.1 In this way you cand get rid from mod manager of site-side features like mod size, nr of downloads, rating. (Or at least from general view, you could still display them in Description page for example).
I dislike that you have to browse 5 mods at a time. When you usually have 10+ it is hard to have a whole view on what you have installed. (Here HoN version I posted offers concise icon only view that makes space for more on one screen. But at the same time offers easy access to detailed description when you select a mod).
TLDR: I like better to have a website where you can discover mods and download them to your local mod manager where you can enable/disable them as you like.
Maybe that’s because you haven’t used it? After having used to such mod managers in games and software store in OS need of manual download sounds archaic for me.
What kind of information you can see on website that can’t be displayed in mod manager?
2.1 Separate view for installed mods and for available to download is another possibility - this is how mod manager works in OpenTTD.
This depends on resolution - I have 7 of them visible at once.
This depends on how GUI is designed - something between HoN and BfW would be perfect. Such data like mod type should be visible in list too IMO.
Website for VCMI mods may be a problem - AFAIK we don’t have anyone with good enough skills to make it. Using forum board is good for feedback but using it as list of mods will result in awful gui (no good searching, no autodownloading of requirements, etc)
Here how much info can be displayed on a site. It helps you decide easier/faster if you want the mod or not. You do not need that kind of info in mod manager. Like I’ve said when I am looking for a mod I care about ratings, nr of downloads, etc. Once I have it on my computer, I care only that I can easily enable/disable/uninstall.
Yes this is definitely needed for Heroes 3.
As for website creation… if you want it managed by VCMI… then you need more than a portal. But my guess would be that an announcement will get you someone willing/able to do one. As a backup plan Joomla, wordpress and the like provide templates for almost every need.
Still don’t see need of a website.
List of visible fields can be changed depending on mod location - already installed locally or available on server.
Same goes to actions list - mods on server will have only one “download” button, local mods will have “disable”, “remove”, “update” (if any)
I think that a website is not required too at least as a start. We can develop a website to allow users/players to discuss, comment and rate mods. Mod developers can add screenshots, a more detailed description and links to discussion forums, videos. The mod administration this means uploading mods, developer user system, … should be website-based IMO. No user/login system required for the mod browser. Website development should be based on a CMS in comparison to a self-made system as it features user privileges, user roles and a template system out of the box.
The mod browser should be capable at least of the following two parts of mod mgmt:
a) searching, adding new mods
b) mod configuration & mod updating
A simple UI design would be that the main window shows a list of installed mods. The list can be sorted by clicking on any columns. E.g. status flag of mod(disabled, enabled). 1+ mods can be selected to allow multiple updates/deactivating/activating/removing and such actions.
New mods can be added by clicking on the button Search or Add mods below the mod list. This opens a new window which is separated into two parts. The upper part has fields for the search restrictions and clear/search buttons. Search restrictions can be category, author, name, download count greater than/equal/lower than,… The lower part shows the result in a list with several columns. 1+ mods in the result list can be selected to be added/installed. A more detailed info about mods as a extra window would be possible, but of 2nd priority.
I didn’t compared my idea with other mod explorers, so excuse me:)
PS: Central repository / database can be maintained by a small group of admins so long as automated mod admin mgmt via website isn’t finished. Mod count should be relatively few at the beginning…
And call it forum? IMO forums are good enough for most of this (and we have one already).
Rating or any other indication of “mod coolness” like d/load count is not a good idea - too easy to abuse.
Not sure if 2nd window for mod search is a good idea - simpler GUI is always better.
Search restrictions - no need to overcomplicate this. Leave one filter box that will search in all fields (name, author, description)
Main GUI may look similar to HoN screenshot from previous page:
top row\panel: text filter aka search tool + droplist to select which mods to show (installed\not installed\etc)
left part - table with 2-3 columns (name, type, author)
right part - selected mod description + action buttons (install/remove, enable/disable, etc)