krs, I think you can try to move at least 1 town to mods and see, if this works (disabled town in .config, move to mod only json configs, but not yet graphics)
If this will work, this can be used for all other standart towns.
First step is to dump all of the original resource files: xxx.snd xxx.vid sprites.lod bitmap.lod in a temporary folder. Armaghedon’s Blade files will overwrite where appropriate.
Second Step a function will parse these folders and move file to appropriate locations. Everything that is faction related will go to that folder the remaining files… I do not know yet.
Temp folder structure will be:
data_temp\
sprites\
images\
sounds\
videos\
misc\
I’ve separated the original H3 files into logical groups. Some more detailed separation can be done in the future if really needed, but for now it looks cohesive enough (EG: group terrains by type, group map editor objects, group interface elements).
For complete separation of towns there are 2-3 def files that need splitting. (EG: Creature portraits are all in one def, town icons are all in one def and I think there was another one).
And a lot of icons: artifacts, buildings, luck/morale, primary/secondary skills, hero specialties, spells, resources, dwellings.
Those are icons for starting bonuses of campaign scenarios. Apart from these bitmaps there are also several .def files for same purpose (can be identified easily by yellow-ish background and “bo(n)” in their names)
Here the .json for Pikeman. Can someone take a look for something wrong? (Not numbers but overall structure).
I cannot seem to be able to find big icons for creatures. (Only for small “CPRSMALL.def”). Is there any documentation/example on splitting a .def file like this?
Abilities are missing?
You may want to dump creature JSON structure somewhere in CCreatureHandler::loadObject - this will give you complete structure including parts imported from crtraits.txt
File names - since you’re extracting everything anyway why not switch to more readable names? E.g.
“castle/PIKEATTK.wav” ->“castle/pikeman/attack.wav”
TWCRPORT.def
You can access frame in .def file using syntax : but there is no straightforward way to extract them using VCMI code.
Perhaps load .def using CDefHandler? This will give you SDL_Surface’s that can be saved as bmp
The Def Preview program as standalone is not helping because there should be no game files redistributed. VCMI has to come with a program that does the splitting automatically from ORIGINAL files.
That being said are there any source codes for Def Preview? Those can be used as model.
Renaming them will cause problems with Original H3 mods. And the renaming gains are not that great since you have a meaningful folder structure with reduced number of files (EG: castle/pikeman/pikeattack.wav anyone can tell what this is).
While it would be great to have nice names for files… the trouble that will cause with original mods is just too much imo. (Maybe a mapping system could be used?..).
Even if you’ll find them it will be Delphi source. Not sure how useful it will be for C++ program.
You’ve already “renamed” them by moving into subdirectories. Mod that replaces “PIKEATTK.wav” won’t replace “castle/PIKEATTK.wav” or "castle/pikeman/PIKEATTK.wav"
And I’m mostly talking about such completely cryptic names like “TPTHBKCS.bmp”.
Can you tell me what that name means without checking how it looks like? Hint - this image is used in town screen.
JsonNode objects can be serialized via “<<” operator:
You have already extracted game files, why bother?
You can copy CRPORT.def (or how it named) or similar files to each monster folder and then address only single frame from it.
I was under the impression it will replace the files. But you are right, so I was wondering anyway… why the extra “castle stuff” (forgot the English word)? Why not dump all resources at the same level? I can think only about using name duplicates. eg:
cove/content/cofig/cove
why not
cove/content/config/
Let me see I have exactly 2 days experience with H3 files so… without looking into file… TownPictureTownHallBacKgroundCaStle.bmp? I am not that convinced about CS. I do not want to say that the names are ok like they are by any measure. For now I will try to finish just moving them and then maybe look into modifying the names. (But off-course we can discus it meantime).
<name of mod>
mod.json
Content/ - directory that acts similar to H3 root. In future will be replaced with .zip archive
Data/
... - represents our directory structure, based on H3 structure. Check config/filesystem.json to see how VCMI generates filesystem from H3 data
Sprites/
<mod name>/ - one more subdirectory to avoid conflicts between mods. Files placed directly in Sprites (or any other directory on that leve) will override files from H3 or other mods.
So if you will place everything in Content/Data … Content/Sprites directories directly without renaming it will replace H3 files as you want to.
But:
This means that you must use plain filesystem without subdirectories (unless you’ll split everything into separate mod). Won’t add much to ease of use or readability.
Placing everything in this way may result in mod conflicts (if 2 mods add same file). Certainly not good example for modders.
1- During my initial import all values equal to 0 were removed. This is why some fields may be missing from config.
And frankly I can’t say for sure what that field is. It comes from H3 data and right now unused in vcmi.
2- They have. See separate text.json file (or something like that)
3- Could be bug. Will check.