SoD files mod like

I will do it your way, but I will say it a last time so that I feel a little better: I really, really find it counter intuitive and I dislike it :).

Attached the latest version with variant A). Take a look and give some feedback please. (I will not start the rest of the factions until we have castle 100% agreed upon).

What still feels not right…

  • there is /sprites/ everywhere. Would look cleaner without it.
  • I have changed everywhere icons structure to icons/large icons/small.
    castle_Data_based_A_Version.zip (37.4 KB)

It looks bad. And there is an issue with standard LOD graphics (that can be used by mod by filename or replaced by mod).
Think about leaving all graphics in LOD and leave only jsons in mod structure.
Earlier I was for moving out graphics, but it will cause too many problems.

If you could detail a little on that maybe we can debate/solve it?

For example, for new town in faction.json I can use standard town graphics like that:

"townBackground": "TBELBACK.bmp",
		"guildWindow": "TPMAGEEL.bmp",
		"buildingsIcons": "HALLELEM.DEF",
		"hallBackground": "TPTHBKFR.BMP",

Only by their name.
If you move these files from root directory (LOD), they will be unaccessible, so there again wll be a lot of work for all existing mods (copying these files back to their places).

Same goes for replacing.
Now in mod folder “Data” I just place file TPMAGEEL.bmp, and it will replace old file in mage guild window. By moving graphics out these easiness is gone.

(Ivan please correct me if I am wrong)… If you make a new town mod just like the one above you can have all images and sprites dropped together inside the /sprites/ folder. You are not forced to use the countless sub-folders I proposed for SoD.

For replacing you have to use /Overrides/<other_mod_name>/<relative_path_to_resource> . The necessity to have this convention in place is explained in the discussion about using the /Overrides folder (the last 7-8 posts) Short version, we need to use <mod_name> when referring to resources so you do not accidentally overwrite files (with same name) in other mods.

Yes we can.
But first, there will be countless duplicates of same files, plus there always possibility some file paths are forgotten to correct.
And second, it will lead to distributing mod with HMM3 graphics. So not only file size will increase,but also possible copyright issues will rise.
Not anyone draws siege screen, for example. So it will lead to several duplicates of standard siege screen graphics (it weights…) And it will consume memory, I think.

I do not understand what you mean by distributing original H3 files with mods… They are copyrighted so modders are not allowed to redistribute them. So that for sure will not happen.

If you are referring to SoD mod redistributing things that’s not accurate. You still need to have your local H3 installed, and a script will place those files in the right places under the VCMI/Mods/SoD/.

To make it short: everything will work more or less just like until now, except that instead of having SoD hard-coded there will be a mod for that. The rest is only talk about moving 1-2 folders around.

The extra work to be done is by modders that modify original SoD files. They will indeed need to move some files to the right places.

You are proposing things that FORCE modders to use HMM3 graphics. Because most of them will not draw their own sieges, etc.
Instead of giving them possibility to address these files by filename you will force them to copy these material to their folders. Or FORCE them to put your mod of std. town to dependencies list. So you will make MAIN mod, that will be addressed by them. So there will be no possibility to turn off standard faction. So what’s than the reason for all this, if instead of flexibility you will force modders to correct their mods and depend on this mod?

One of the things SoD as mod will enable you to do is to turn all SoD (aka Heroes 3) completely off and play MarioKart MoD on VCMI engine. Or more realistically, you can turn off some of original factions (like conflux) and play HotA with the remaining plus the cove faction.

Edit: Another example: With SoD mod you will be able have a mod that allows you to play H3 with H2 graphics… (provided you have a copy of H2).

So if you ever need a file from SoD everything will behave like until now, the file will be there but it will not be hidden in a “core” hard-coded feature. So theoretically you can do all that you did until now, and a little more but in a more transparent way to the modder.

As workaround I can make core-mod:
mod.json (file without json paths)
Content/Data (all graphic files from original LOD unpacked here)
Content/Sprites (all sprites from originl LOD unpacked here).
It will save my time from correcting existing mods.
But I think it will be processor-consuming.

krs, I wish we could use some tag-based filesystem here - it will certainly make things much, much more easier here :slight_smile:

Regarding your Castle data:
Paths like “/sprites/town/image.png"
It is completely possible to have multiple factions in one mod (e.g. two interconnected factions that can’t be split into separate mods). Meaning that paths here must be like this:
”/sprites/factions//image.png"
Same goes to your proposition aka “C version”

  1. Certainly not “forced”. I’d like to have such files arrangement as “default”. That is, if path to file is not present in config, game will try to load data from such default path.
    Don’t forget that H3 objects including towns use exactly same mechanism as mods so some way to override such default paths will remain (like specifying them manually in config).

  2. If modder wants to replace file from H3 or from mod he must use Overrides directory. For mods it should be placed as “Overrides//” for H3 it must be Overrides/core/.

We talked about using by filename, not replacing mostly.
What’s about links by filename from LOD?
Is it planned to move all graphics to mods?
Or standard LOD will stay attached to filesystem and continue be used by filename?

Moving it is unlikely. But in some cases H3 data will be accessible as mod named “core”.

Yes.

And don’t forget that these filepath changes won’t be implemented soon - right now my main focus will be mod manager/zip support. When this is done I may work on changes proposed in this thread.

So all resources for a faction must have again /castle folder? (cratures, heroes, town…)?

Then +1 to my entity (non_data_based) structure :D. You have a mod name once and that is it.

I will do it and post it again here. Besides that am I good to go with the rest of the factions?

OK. In part of moving std. factions to mod this is great. In part of moving out graphics I don’t agree. So will wait, maybe in 0.94 we can finally choose only needed factions for game.

Here the latest modifications. Added a /castle folder after each of /sprites/ , /sound/, /music/

Hope I got it right.
castle_Data_based_A_Version2.zip (38.4 KB)

No. Only resources of faction itself (creature backgrounds, town screen, etc).

Full filename (including path) must unique identify resource. To do this it must contain:

  1. name of mod, auto-detected for files in Resources directory.
  2. “type” of data (sprite, icon, config file, etc)
  3. “type” of object this file belongs to (faction, hero class, etc)
  4. identifier of object (castle, rampart, tower…)
  5. what this file contains actually contains (if applcable)
    Example:
   (2)     (3)      (4)    (5)
/sprites/factions/castle/creatureBackground120.png

   (2)     (3)     (4)
/config/factions/castle.json

Order of this elements is debatable but all of them must be present, if applicable.

And perhaps tag-based filesystem is not as crazy as it seems? It would be “everyone happy” solution for this situation. :slight_smile:

  1. As I said - no need to put creatures/heroes in castle directory
  2. In some cases like music - each town has only one music file. So it is OK to use
    music/factions/castle.mp3
    instead of
    music/factions/castle/theme.mp3
    Same goes to config files IF you will merge them into one. I haven’t done this for Cove due to large size of resulting file so this is up to you.

UPD:
fixed music paths.

*complaint about uncomprehensive mod system removed by user.

I did a new version. Please again take a look because I really have difficulties understanding what should go where. (for faction). I hope I got it right.
castle_Data_based_A_Version3.zip (38.9 KB)

Directory /sprites/factions/castle/
Perhaps remove “town” directory?

Directory /config/factions/castle/
As I said - if you wish you can merge (some of) config files here.

Directory /music
Create directory “factions” and move all town themes in it during data import

Directory /sprites/creatures/battle/projectile/
Perhaps move it one level higher and keep “battle” exclusively for battle defs?
So all projectiles will be in /sprites/creatures/projectile/

Directory /sprites/factions/castle/town/townScreen/
What’s the difference between “buildings” and “animation”?

Directory /sprites/heroes/
I assume directories for hero icons are missing? Or you’re not importing them because H3 keeps them in one file?

One more thing - heroes and hero classes. It is better to split them into separate directories (in config and sprites)

And regarding first level directories that you don’t like (sprites, config, sounds…). One of the largest reasons behind them being required is current code - it is quite difficult to make them optional or remove without breaking existing code including data from H3 txt’s.
One of those big cost/little gain situations. :frowning:

Ok ty for your time to review the structure. I have uploaded the latest/final version with all the points you had addressed. (except combining .jsons. I got used to them this way, but after all is done I can merge the ones you want. Will take 5 mins of copy/paste).

So: /sprites/town removed, Music/factions created, projectiles moved to /sprites/creatures/projectile/, unused buildings folder deleted, missing heroes/icons added, heroClasses separated.

Please throw a last glance an I will start updating the rest of the factions.
castle_Data_based_A_Version4.zip (38.8 KB)