Horn of the Abyss

Updated mod for 0.95, will upload to repo once release is out.
dropbox.com/sh/fwor43x5xrgz … s/cove.zip

Changelog:

  • update for vcmi 0.95
  • updated mod using data from HotA 1.3.2
  • now mod includes several new heroes added by HotA (technically not part of Cove, will split it into separate mod a bit later)

New version makes Cove Tarnum incompatible, as seaserpent identfier has changed.

Internal identifiers are never supposed to change once the mod is released!

Until VCMI gets 1.0, it’s not neccesary :slight_smile:

In my mods I use prefixes, by the way. I think this rule may be used by officially released mods to distinguish IDs (source of origin) and to prevent conflicts of names (when for example, hero’s name in one mod is the same as in other mod).

I think Cove may be changed this way also:
for example, creatures IDs may became “coveSeaSerpents”, “coveCorsairs” etc.
Heroes name also can be like “coveDargem” (or even “coveHeroDargem”). Same for classes.

Ok, will revert. I’ve updated some of them to match “official” translation but probably changed case in some places (I assume problem comes from seaserpent->seaSerpent change).

No. VCMI supports same ID’s from different mods. For example both Cove and WoG have sorceresses. And they do not conflict in any way. So no need to overcomplicate things with prefixes.

This issue have been solved?
Still there is issue about readability of configs.

I only now understanded, why building dependence must be corrected - after I played map with new towns.
“requires” : “allOf” , “dwelling1”]],
is not enough.
It must be corrected to
"requires" : “allOf” , “fort”],“dwelling1”]],

Because, when there is a map when some dwellings are present, they are allowed to build even no fort is here (if “dwelling1” is built.
Will be correcting my buildings.json

No, this is a bug, not something I intended to do… Same thing would happen to H3 towns. And one that does not have a trivial fix that I’m aware of… Will see what I can do.

I propose to not rewrite something (new bugs will arrive), it’s just to add “fort” to “ofAll” to all dwellings 1-7. It’s easiest and most reasoned fix.
I have at least one town where fort is not present at all, so buildings builded without it.

CASTLE WAS:
“dwellingLvl1”: { “id” : 30, “requires” : “fort” ] },
“dwellingLvl2”: { “id” : 31, “requires” : “dwellingLvl1” ] },
“dwellingLvl3”: { “id” : 32, “requires” : “dwellingLvl4” ] },
“dwellingLvl4”: { “id” : 33, “requires” : “allOf”, “blacksmith” ], “dwellingLvl1” ] ] },
“dwellingLvl5”: { “id” : 34, “requires” : “allOf”, “mageGuild1” ], “dwellingLvl4” ] ] },
“dwellingLvl6”: { “id” : 35, “requires” : “special2” ] },
“dwellingLvl7”: { “id” : 36, “requires” : “dwellingLvl5” ] },

NEEDED TO CORRECT
"dwellingLvl1": { “id” : 30, “requires” : “fort” ] },
“dwellingLvl2”: { “id” : 31, “requires” : “dwellingLvl1” ,“fort”] },
“dwellingLvl3”: { “id” : 32, “requires” : “dwellingLvl4”,“fort”] ] },
“dwellingLvl4”: { “id” : 33, “requires” : “allOf”,“fort”], “blacksmith” ], “dwellingLvl1” ] ] },
“dwellingLvl5”: { “id” : 34, “requires” : “allOf”,“fort”], “mageGuild1” ], “dwellingLvl4” ] ] },
“dwellingLvl6”: { “id” : 35, “requires” : “special2”,“fort” ] },
“dwellingLvl7”: { “id” : 36, “requires” : “dwellingLvl5”,“fort” ] },

This is needed for “dwellingLv1”-“dwellingLv7” only.
Pleeeeesee, do not rewrite currect buildings logic, it’s ideal!

Fort is just the most obvious source of this bug. For example Monastery (Monks dwellings) requires Mages Guild lvl1, while Upgr. Monastery requires only downgrade.
So if map maker will create map with built Monastery but without Mage Guild it will be possible to upgrade dwelling without building the guild. This IS a bug. And multiple buildings have it - this is first example I found.

I’m happy with current format but internal logic needs to be fixed.
went to Mantis to create report

CASTLE WAS:
“dwellingUpLvl1”: { “id” : 37, “upgrades” : “dwellingLvl1” },
“dwellingUpLvl2”: { “id” : 38, “upgrades” : “dwellingLvl2” },
“dwellingUpLvl3”: { “id” : 39, “upgrades” : “dwellingLvl3” },
“dwellingUpLvl4”: { “id” : 40, “upgrades” : “dwellingLvl4” },
“dwellingUpLvl5”: { “id” : 41, “upgrades” : “dwellingLvl5” },
“dwellingUpLvl6”: { “id” : 42, “upgrades” : “dwellingLvl6” },
“dwellingUpLvl7”: { “id” : 43, “upgrades” : “dwellingLvl7” },

CASTLE WILL BE
"dwellingUpLvl1": { “id” : 37, “upgrades” : “dwellingLvl1” },
“dwellingUpLvl2”: { “id” : 38, “upgrades” : “dwellingLvl2” },
“dwellingUpLvl3”: { “id” : 39, “upgrades” : “dwellingLvl3” },
“dwellingUpLvl4”: { “id” : 40, “upgrades” : “dwellingLvl4” },
“dwellingUpLvl5”: { “id” : 41, “upgrades” : “dwellingLvl5”,“requires”:“mage1”,“dwellingLvl5”] },
“dwellingUpLvl6”: { “id” : 42, “upgrades” : “dwellingLvl6” },
“dwellingUpLvl7”: { “id” : 43, “upgrades” : “dwellingLvl7” },

Personally I think that changing config is easier then do something with logic.

City Hall, Capitol, all dwelling upgrades where base dwellings have dependencies, possibly - some AI-specific cases (town hall screen restrictions are player-only)

Personally I think that changing logic is proper way to fix bugs. Not ask modders to look for workarounds.

I tried to play new Cove with 0.95. There is something wrong with artifacts - they just don’t spawn on the map.

However, cheat vcmiforgeofnoldorking can create them and they seem to work. Additionally, I figured out that crown of Seven Seas can’t be moved and console recognizes it as a lock - it’s the first artifact after three unused combo artifacts.
Also, I have WoG disabled for now.

That’s strange - they should behave exactly as any other art mod. Will check this out.

Just one thing - Cove creatures are one level higher than they should be. This may cause crash on map launch if level 7 creatures are present.

In my client log there is a messages like

10:46:12 WARN global [13b4] - File CONFIG/HOTA/KULA is not a valid JSON file!
10:46:12 WARN global [13b4] - At line 1, position 0 error: Not a valid UTF-8 file

After recoding files to UTF8 without BOM it worked well (but polish characters got broken). I don’t know polish so I left them corrupted

Updated for 0.96 version here:
dl.dropboxusercontent.com/u/223 … s/hota.zip
Note:

  • Requires bugfixes from git to work. Will crash on 0.95d
  • Will be uploaded to repo on 0.96 release.

Changelog:

  • updated using 1.3.3 data
  • converted it into set of submods (note that this will break mods that depend on “cove” mod). Cove is now a submod of HotA.
  • implemented (as a separate submod) new graphics for towns on map (including H3 towns)

In dwellings there are strings “guards”:true
It leads to unguarded dwellings in my test mod.
In my test mod I replaced it with
"guards" :
{ “amount” : 16, “type” : “abodeDruid” }
],
for example,
and now guards work.

Should you not tag the new version of the mod as incompatible with old ‘cove’? Now I have both of them installed, which makes 2 separate cove town avaible in single player scenario settings :slight_smile:

I also noticed some bugs:

  1. Right after downloading ‘hota’ mod you cannot immediately expand the submod list (the arrow is missing). You have to restart the launcher. It would also be nice to add ability to simply double-click to expand the tree as this does not work.
  2. Why do I have to ‘cove’ submods’ (screen)? :slight_smile:

Btw., I guess I should update my mod (Tarnum pt2), therefore I have a question, how do I make it compatible with a submod? In WIKI there is only this (main mod as I assume?):

// List of mods that are required to run this one
"depends" :

    "baseMod"
],

Finally, a question - does the new version of mod mean that in the future all the features from hota will greadually be added to this mod (objects, maps, other towns etc.)? Just curious :slight_smile:


Thanks for report, will fix all of these soon.

One of these was supposed to be new towns for map from HotA (village->fort->citadel->castle->capitol chain). Probably messed up something with release package - it was OK before.

For submods format is .. So what you need is this:

"depends" : 
  
 "hota.cove" 
 ],

Yes. Features ported from HotA will be added to this mod. But I have no intention on copying HotA 1:1. Some examples:

  • Graphical fixes for h3 - won’t be ported. At least by me - I don’t want to distribute half of H3 graphics from vcmi.eu
  • Map objects - likely to be possible in 0.97 but quite useless without working RMG or editor. I will port them once RMG will be more-less stable.
  • Maps/campaigns. Almost impossible to port without converting to some kind of VCMI format. And for that we need our own editor first. So this will take quite a while.

By this do you mean new versions of ie. new Hydra Pond and Efreeti map objects, castle screen fixes/changes etc.?

Would it not just be easier in the future to make VCMI simply HOTA compatible and configurable by JSON files instead of extracting and repacking graphics? In the end it is one of the best things that happend to Heroes 3 in a last couple of years :slight_smile: