Now we only need to find someone who will implement all of this 
To be fair - I donāt think that this will be done soon. I already have more than enough left to do and I am sure that the same is right for everyone else in our team.
This most likely will be implemented at some point, but not now.
Thatās true. Mhhm what about label newly added mods(within 1 month)? Perhaps itās better to abandon showing d/load count and rating from āofficialā side as they could be meaningless or mods may have it more difficult to reach a greater popularity. Donāt know if thereās some sort of true rating ever possible.
ā¦ yes! Perhaps it would be just OK to allow mod devs to add a link to a thread of a forum(our forum!) where the mod can be discussed. The link can be presented below the mod description.
For a list of available mods we could also use our wiki. There can be several pages for the different types of mods. A link to the discussion thread of the mod can be added as well. That would be a simple solution!
Ok, complex search restrictions arenāt needed as we have only a few fields. That way we can save an extra window. Perhaps mod category could be added as a drop down box near the filters text field.
I think the goal for the following month is to make any mods at all come true.
We need two things for that purpose:
I really believe weāll easily sort out mod web service once they get a lot of attention. Before then, however, itās empty fun.
@Warmonger you spend too much time at HC :). Suggestions are what they areā¦ suggestions.
Personally I had some ideas/questions and by sharing and confronting them with others I learned a lot about how VCMI works or how it is intended to work. (Not like it is full of documentation or something 
)
Thinking in advance as thoroughly as you can and exchanging opinions always saves you from having to rework stuff later.
Where to put that one without coding skills could work in parallel on implementing the site.
I think the problem of mod selection would be best solved by something like graphical package managers in Linux. The problem becomes quite complex when different mods evolve and intricate dependencies arise.
I think about players using tens of small mods making small changes and big mods that gather them in balanced sets. There could be also more than one mod repository too.
Anyway, adding creatures, artifacts and towns is certainly not enough to attract modders.
In the HoN example in header files there were 2 entries for each mod: a list entry for each mod called and a list entry for . When you wanted to enable a mod, the manager looked in this fields and the list of enabled mods and granted or denied you the right to activate/disable it.
@krs
Linux package managers are designed to handle such situations as well as more complex ones. And do this job quite well. At least most of the time.
In case of repositories there should be some machine-readable āindex fileā. So wiki will work only as alternative to mod manager which somebody will have to keep up to date. Or there must be a tool\bot\script that will keep them in sync.
Link to discussion can be made part of mod format. Similar to how most Linux packages have ābug report URLā
But itās fun, empty or not. Fine for me 
Why one repo wonāt be enough? Or are you talking about user-provided repositories aka AUR/PPA for Linux?
Iām talking about user-provided repositories. This way we could remove bad mods from official repository and tell its developer to use a separate one.
Anyway I donāt like that there seems to be no package management library. Everybody implements their own tool from scratch.
What do you mean with bad mods? There should be a minimum degree of mod guidelines sth. like this:
For such mods a separate repo would be nice. From a technical point of view it shouldnāt be that much more work. But users can always copy mods manually into mod folder.
There are many way a mod can be bad and you mentioned two of them. I could add experimental work and mod forking (bad until significant nonnegative difference is seen).
Copying mods manually is an option, even turning them on and off, but it shouldnāt be necessary for a novice player.
One more breaking change into modding system. Should be the last change before next release.
āfilesystemā entry is now optional and any paths inside it are relative to mod directory. Removing āALL/Mods/modnameā prefixes should make mod working again.
Default value is ācontentā directory that acts as game root directory (this is how resources are organized in cove and new menu mods).
So after renaming āOverrideā to āContentā filesystem entry in mod.json is no longer needed (+1 to simplicity)
Updated links for mods with these changes:
Cove: dl.dropbox.com/u/22372764/vcmi/mods/cove.zip
Main menu: dl.dropbox.com/u/22372764/vcmi/ ā¦ w-menu.zip
How can I install Cove and artefacts packages to VCmi 0.91?
Didnāt find more suitable topic: i have a request for a creature special ability. Bonus defence aura, all adjected ally creatures get +x defence or +x% defence. As I can see, there is only spell resistance aura bonus available in the bonus format =(
To game developers:
Somewhere I read that this version would bring us new towns?! Sincerely speaking I donāt have to much time to kill on the PC, and when I have, I like to play heroes 3 (wog and why not vcmi) and not to read about this games. I always was fascinated by the thiefās, I see that at wog with the SCOUT skill you have some new options. Now I wonder, would ask here, would it be possible to create a new class? New town and new abilityās with skills? Or this would ask way to much time and development?
Iām thinking of THIEF class with their town and 2-3 new skills for thief specialty and ability for thief class only.
Much appreciated your answers.
One problem with current mod system that becomes more visible: it is possible to access string IDās from any other mod.
Iām going to restrict this to mod dependencies. So if mod A wants to use identifier from mod B it should be marked as required. Othervice - failure to resolve identifier on startup.
Second problem: What to do with ID conflicts? How to distinguish same idās added by two different mods? May become a serious problem later when IDās will be used more widely.
Perhaps add āfull IDā that will consist from 3 sections: ..?
Of course it should be allowed to use short versions when possible (read - locally in configs) and keep long version for scripts or conflicts resolution.
Or we should allow objects with same IDās?
+1.
I cannot make up my mind. Iād definitely allow mods to add non-prefixed creatures (and make precise rules for conflict resolution like mods are loaded by priority and itās the sequence of adding things etc.) for the sake of generality but local, auto-prefixed, defenitely-not-conflicting creatures might be a good idea too.
+2.
This seems like the best solution, AFAIR it has been somewhere here agreed upon.
Within the mod you should be able to use just the name for things that are defined within the mod.
Possibly we can also allow using short version for mods that have been explicitly listed as dependencies (some kind of āusingā directive would be nice). However when name conflict occurs (two dependencies or dependency and āthisā mod uses the same name) I think it should cause a hard error, that is issue diagnostic and exit. Iām afraid that adding conflict-resolution rules might easily lead to silent errors in mods. (Well, it can be always added later anyway. Iād start with more strict rules and relax them later if appropriate.)
And what if person A does forge town as mod, person B mod āall forge units (that is prefixed with forge) get --somethingāā and person C wants to make mod adding new unit to forge town from Aās mod? Bās script shouldnāt work with that unit? If mod name will be enforced to be really the modās name, then C wonāt be able to be compatible with B.
B & C script should rely on faction id rather than identifier prefix, and they will work.
Hosting provided by DigitalOcean