I wanted to say that now you do not compress mods and that CPU usage will increase once you do.
The idea was that you will have a lot more examples to point the people to. All sorts of creatures…
This is the answer I was expecting all along. That this makes some sense but there are some hurdles atm.
How about this: I implement the whole moving thing (did some parts already as test) as an VCMI_ckient.exe option but leave the original files in place! and see how people like it. (so when you run client with a specific option SoD mod is created with files in the right places but inactive.) If by any chance VCMI code will never support this, at least modders could have a nice reference.
For this I will need very little help, mainly in the form of: “is this file structure ok?”: or “what is the purpose of these files?”.
You may want to make it as separate binary (linked to vcmi library to get support for H3 formats).
VCMI should support resulting directory structure - filesystem support is quite flexible here. But I’d like to keep this separate (unless other devs will propose to include these changes in vcmi).
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).