Serpen fly has “extraNames” : “dragonFly”] which forces dragonFly to be named fireDragonFly…
For SoD as mod, can I get rid of this extra name and rename fireDragonFly to dragonFly? Would this extra name still be used to read some txt files that cannot be translated into .json files?
For some files I ended up with stuff like this:
cerberus before CContentHandler::loadMod():
""FLYING_ARMY" : {
"type" : "FLYING"
},cerberus after CContentHandler::loadMod():
"FLYING_ARMY" : null,How to treat this? Why does this appear / is necessary?
On serpentFly: IIRC only file that has incorrect names is HTRAITS.TXT or something like that - starting armies of heroes.
VCMI will always read that data but it will be overridden by json data.
And check all creatures that have such “extraname” and stone/iron golems.
On null:
Same reason as above - incorrect data in CRTRAITS.TXT.
If you check Cerberus entry in this file you will see “FLYING_ARMY” entry. However Cerberus certainly can’t fly - this is why this bonus is removed via json (see creatures/inferno.json).
You need to either keep this or fix CRTRAITS.TXT file because vcmi always reads this file.
Oh and just in case:
"FLYING_ARMY" : null,Stands for “ability removed”. Same trick can be used by mods to remove ability from another mod or from H3.
Not if I have my way with SoD mod it wont :D.
Once every config is inside SoD mod there will be no need of reading CRTRAITS anymore.
OK so for now I will just remove the wrong entries.
I am now sorting some more sound files… have some that do not know where they go.
EvilEye Beholder have stuff like: “attack”: “dungeon/BHDRATTK.wav”, which is standard, but then some sound files like: BHDRDETH.wav. what should be the entry name for it? “death” : … ?
Configs for puzzle maps for each faction seem to miss the 00 index.
EG. I found images like “puzcas00.bmp” and no entry in config.
Is it a mistake? or are the config files not 0 but 1 indexed?
1)Perhaps you’ve found some leftovers from development. Death sounds usually have “KILL” suffix:
"killed": "BHDRKILL.wav",SoD as Mod.
Purpose: The long term purpose is to have all of original SoD content as a mod with its own configuration .json files and all the Data moved to the corresponding folders.
Current status: Since the modding system is not complete yet the mod will not work out of the box and some folders are only used as a placeholder to store data (without any mod functionality. EG: campaigns, interface). Once more functionality is added to the modding system, more config files can be added to this structure.
What is different:
What is missing:
How it works:
Installation: (I haven’t committed anything to svn)
Note: It takes some ~5mins to run. (it will be executed only once tough on the first installation)
SoD_as_Mod.zip (507 KB)
Keep up the good work.
So far it seems this project will be very helpfull to me with Legends. I will certainly need a feature to turn off/change stuff and things from SoD so this is really great work.
Glad someone is interested in it. That is one of the greatest benefits this mod provides. Making it easy for other mods to change/turn off SoD original stuff.
The modding system is not finished yet. While the .json files I provide are complete (for the supported mods) the modding system needs some minor changes approved/debated/done by a developer. (If they decide it is worth it). Once that is done, I will continue working on adding missing stuff like creature abilities, and start working on porting the H3 with H2 interface Mod.
By these “minor changes” you mean submods support?
As I said - I’m not yet sure what’s a proper way to implement them (both coding side and how it looks in mod).
BTW - what about merging 4 mods that you have for each faction into one? There is no huge need to keep them separate as long as internal structure is OK. And if all town mods will use such structure it will only create unmanageable number of mods for user.
We have debated briefly this point before. But got to not real solution. I see the submod implementation as simple as this: (SoD as example): look in SoD root folder. If there are entries in “modList” load the mod from the folder specified there. Maybe I am missing something obvious but this should take no more than 15 mins to implement. And it will allow us to organize mods quite nicely (as opposed to forcing every mod to be dumped in root mod folder).
Frankly I just copied the HotA structure :). The only realistic advantage I can think of in having things separated is that you could play with lets say conflux creatures but without the town or better yet without the heroes. But even that is quite far fetched… so I agree there is no “real” need/advantage in keeping them separated.
The downside is that the indirection will be moved from mod to every resource file. (Lets take a creature, angel.json for example). all paths will have to be modified from “castle/adventureMap/AvWAngl.def” to “castle/creatures/adventureMap/AvWAngl.def”? Or we just dump adventure map resources for creatures, town files, heroes into one folder?
Say the words and I start merging them :).
minimods:
It certainly not “obvious” but current code won’t allow submods easily - it certainly not 15 minutes but something like 1 day to make it work and even more to write it nicely. Also - due to how our filesystem works submods should be implemented differently - e.g. subdirectory in mod directory.
merging:
Exactly my thoughts. Multiple mods were useful on early stage of development but now they only add to complecity (especially with new workaround files/faction mod)
I’m thinking about some ways to decrease currently numerous nested directories:
When this is done paths like “modname/sprites/adventureMap/creatureName.def” won’t look as bad as they do now (at least in filesystem). Maybe even make all path entries in json optional in favor of autodetection. In this case we’ll need to consider how such default path will be constructed.
(any other ideas to improve filesystem are welcomed)
I am not sure I understood you completely about splitting content/ in 2 parts. But I gave it a shot at combining the 4 separate mods.
1)I simplified the folder structure by getting rid of “castle/” indirection. I do not see its use since we are already in the castle folder. (Plus unique names are used anyways).
I do not think that auto-detection of folders should be in place/common practice. No matter how fast it is, it will still slow down loading of mods. And to have full “hardcoded” paths the modder just needs a good text editor and 2-3 minutes. (EG: sprites/creatures/battle/xxx.def)
If you look at structures.json. There should be paths for animation, border, etc. Right now I think they are hardcoded. Easy solution would be to ahve them in full “sprites/town/townStructures/animation/xxxx.def” but that is a mouthful. So I propose an entry to be added, something like “animationRootFolder” : “/sprites/town/townStructures/animation/” and leave the entries like they are.
Attached the new structure and configs. Let me know how it looks.
castle_mod_new_structure.zip (37.2 KB)
What I meant is replace current Content directory with 2:
Data - acts as current Content directory BUT all files will be placed in “modname” directory. So path “/Data/Sprites/sprite.def” will be accessible in-game as “Sprites//sprite.def”. Will also remove need for unique filenames.
Override - acts exactly as current Content including need of subdirectories. But it will be used only to override files from H3/other mods.
Renaming is needed mostly to avoid breaking existing mods - so Content directory will function as before for 1-2 releases.
Speed decrease is extremely unlikely. Last time I checked most performance-heavy areas in mods loading were related to JSON access (huge number of string comparisons).
Plus it will remove need for your point #3. So for example paths to animation can be generated as “sprites//buildings/.def”
Another benefit is that it will encourage more “clean” directory structure instead of dumping everything in one directory using naming conventions only author know about (H3-style).
I see you are still thinking in /Data terms… Keep in mind that once the SoD mod is in place there will not be a /Data folder!!! Everything will be starting from /Mods.
This will simplify the modding a ton. You want to replace /faction/castle/creatures/archer/sprites/xxxx.def you just have an entry in your mod /faction/castle/creature/archer/sprites/xxxx.def.
(It can be further extended for partial stuff but that could get complicated (it is done in other games though link chapter 5 gives you an idea about what fields will be needed, like <apply after/before mod>).
So there will be no need for a split of the Contents folder. You want to replace a file just include it in your mod under the same relative(to Mods) path! and specify a mod order.
Actually no. It’s just bad choice of name that matches H3 directory name 
Perhaps name it “Files”?
Mod structure will looks like this:
<modname>/
mod.json
Files/ <- Contain all files *added* by mod, without nested <modname> directories
Sprites/
Music/
config/
...
Overrides/ <- Contains all files *replaced* by mod
Sprites/
Music/
config/
...So most of files will be placed in first directory, e.g.
/Files/sprites/sprite.def
But if modder wants to to replace file he will use second one:
/Overrides/sprites/H3file.def
/Overrides/sprites/anotherMod/sprite.def
I prefer this to HoN approach because:
Downside is lack of “when to copy” conditions but I’d rather avoid them if possible - something like this should be left to scripting.
Please indulge me one last time. (I really disagree with having 2 separate hierarchies where the modder has to look for overrides and original data in different places).
It is much more intuitive for people to have all the contents in one folder structure and not to care what are replacements and what not.
So you look at all mods with all files and all replacements and create a virtual (or not) filestructure starting from VCMI/Mods/. All files appear only once and (the overwriting order as to be specified in mod config EG: Load HotA after SoD).
Below is how you would replace original pikeman.json from within HotA. You just put the right file in the correct place in the hierarchy. The engine will not really know about SoD and HotA it will just load all the factions there are, in the specified order.
/VCMI
/Mods
/SoD
/factions
/castle
/content
/config
/creatures
/pikeman.json
/rampart
.....
/artifacts
..... SoD artifacts
/HotA
/factions
/cove
/content
........
/castle
/content
/config
/creatures
/pikeman.json
/artifacts
..... HotA artifactsThis will result in name conflicts. One example that we already have is Enchantress. Creature with such name is present in both WoG and Cove.
These two mods are completely independent from each other, these two creature have nothing in common apart from name. How such situations should be handled in your system?
I don’t see need to enforce that. Modder can place his own files into Overrides directory just as well (preferably into subdirectory). “Files” directory only helps with removing one level of nested directories.
For me this two “types” of data are very different. “Files” are under complete control of modder - he can place anything anywhere in it and does not have to follow any conventions. “Overrides” exists primary to access other mods. Meaning that names of files in this directory must always match filenames in base mod.
Perhaps.
My idea is that as long as modder makes his own, independent mod he should not care if file or object with same name is present in any other mod out there.
And if he wants to change object from another mod he must specify that mod explicitly (for example - by creating directory with such name).
You must have not used any properly configured/administrated system, have you? Otherwise you’ll know, that having some ‘initial/default’ values and place for overrides is best practice. It easies maintenance, such as upgrades (no merging nightmare or overwrite risk), resetting, testing changes (by moving single directory) and probably most important - it the right thing to do with multiuser environment (there might be some system-wide mod prepared by administrator and personal mods in users’ home directories).
Please think wider than windows’ “all stuff into single directory” rule.
Hosting provided by DigitalOcean