Will ERA or WoG/ERM, or HotA, work out of the box?
How will scripts work? I see new json configs, How will these blend with old H3 files.
This is what I could think of quickly maybe there are other aspects regarding backwards compatibility…
If by out of the box you mean that mods made for SoD\Era\WoG will work as it then unlikely.
For example WoG and HotA replace same files (e.g. creature icons). I don’t see any way to make both of them work without some manual tweaking (like in current cove package).
Right now HotA uses encrypted binary to store all HotA-specific data. Using it does not sound like a good idea for me.
ERM from WoG won’t be completely portable - for example direct memory access (UN:C IIRC) wont work with vcmi - we use different structures at different addresses. And I am not taking in account that this is extremely unsafe.
IMO the best approach here is to release our own versions of all these mods or at least some compatibility patch.
Main game (H3:SoD) definitely should work out of the box
VCMI must be able to read all H3 text files, no matter where they are coming from (e.g. Sod or WoG). Json configs may override H3 data where needed (e.g. incorrect starting hero armies).
Or at least this is the idea. Implementation is still not perfect.
This was my impression also. Then why all these “rigorous” rules about reading old H3 configuration files? It seems to me that everything will run smoother if new files are used (like the proposed ones) and compatibility with H3 files is forgotten (not game compatibility, only some file compatibility).
It is easier to implement, a ton more easier to maintain and a whole lot easier to create future mods. The only place where it will be a little more work would be at porting mods. But once ported the time will be gained back when upgrading them.
Old H3 configuration files have translations. We do not support all of them but we could.
VCMI should support translations, so when you “repackage” the resource files you copy the translations over as-well.
Easier implement compared to already existing system? All missing parts are here for one reason: these features were not needed before 0.9. Fixing this is a matter of several days at most.
Easier to maintain? I don’t remember any bugs related to incorrect parsing of txt’s for a long time.
Easier to create mods? Why? No matter how H3 txt’s are handled mods will consist only from json files. Even for some rebalance mods that modify H3 content.
- Right now VCMI can be installed on any localization (or at least Russian) and will not replace it.
- Replacing only text files won’t be enough for localization support - main menu images, multiple buttons, maps. This will only result in awful mix of localized + non-localized content.
I made this thread to clarify for me some points from how VCMI works. So I made some assumptions that may be wrong.
Easier to implement - it seems to me that is not quite easy to modify or add features to existing game content. Ex. Modify only a hero skill. And even harder to modify skills for different heroes in different mods. (I am not talking here about present modding system by how a future one will do those things)
Easier to maintain. - you made a mod to hero skills and want to change them. You have to go to H3 format to do that. Instead of nice json config files. That are more structured and readily available. (you can even diff them)
This is the part that puzzles me…Maybe someone can clear this out for me. I understand this as having 2 systems in place. One that handles H3 files and one that handles modifications. This is where my question originated. Why not handle original H3 data exactly like a mod in the VCMI mod folder?
No. There won’t be any difference for modder whether object (hero, creature, etc) comes from H3 or from some mod. All he needs to know is string id of object he want to change. Everything else will be handled by engine.
How this will work:
-
Engine reads (incomplete) H3 text files and loads all available data into internal classes (CHero, CCreature, etc). Resulting data is unusable at this point of loading.
-
Engine reads VCMI config files (+ mod data that modifies H3 objects) and merges all configs of the same type into one structure.
This will be done by our Json parser so we do not need to implement anything else. Such merging is already implemented (and used) but right now main game and each mod are completely separate. -
Resulting structure (which already contains all modified data) loaded into our internal classes, replacing any data from H3 texts. This creates correct data that can be used by game.
Ty for the explanation. Even if that was my understanding also your description confirms it and makes it a little clearer.
For example: I wanted to modify the creature names (in json) to match the actual situation in-game. And ran into problems because Hero starting creature file that was still in H3 format. So if these files are kept (for whatever reason) you will never be able to get rid of the old names. Any mods that want to modify these will use .json but will abide by the constrains of the internal H3 files that were loaded but will not even get used.
I ran into this particular case but I am sure there are some more. So what I was proposing was get rid of as many H3 files as possible and make them available only as json configs. (You have provide them anyways for modding purposes ). That will be some work once but later is only reuse. (Like I’ve said I do not know how localizations enter into the frame, but VCMI should provide localizations for mods so H3 localizations could be supported too the same way).
This is more like exception from the rules.
H3 does not reads creature names or abilities name from text files. Those names are “reference only”. Usually those names are correct but sometimes they are not. Moving creatures from starting armies + creature abilities completely into json will fix this perfectly. No need to abandon H3 texts completely - the only problem here is that VCMI is too smart 
Why we need to provide them? Modders will have to write their own files.
Example - mod that will decrease HP of Pikeman will consist from this json file:
{
"pikeman" :
{
"health" : 8
}
}During loading this config entry will be merged into VCMI config for pikeman (the one in creatures/castle.json) and then loaded in game, replacing value from H3 texts. No need to provide H3 creatures configs.
Definitely low priority - currently it is possible to make mod that will replace only localized content (of another mod). Some full-scale localization system is nice but this will require too much work.
That is what I meant for providing them :). Have a base as .json in VCMI folder and then start from there.
The above idea looks very good. That feature will allow different mods to change different things on same config file. (Forgive me for stating the obvious…)
Here your answer to moving HOTRAITS.TXT that makes me think that somewhere there is a different approach for different H3 files: