Horn of the Abyss

International board Content creation
#1

Not a new mod but certainly deserves some central place with all information about its status :slight_smile:
For those who don’t know - the town is part of Horn of the Abyss addon, all credits should go their team.

https://dl.dropboxusercontent.com/u/22372764/vcmi/vcmi-cove-full.png

What is already here:

  • Town and all related content: creatures, heroes, adventure map dwellings.
  • Special abilities for creatures/heroes, albeit sometimes not identical to HotA.
  • English version, using data from acidcave. Luckily we don’t have most of text data from HotA (campaigns and maps) so translating town is much easier than translating whole addon.

What is still missing:

  • Most of features from HotA addon.
  • Cannon.
  • Two special buildings are non-functional: Grotto and Thieves Guild
  • Maps & campaigns
#2

Who made the creatures for the mod? How did you get their traits? I’m asking this because I’ve compared the CRTRAITS.txt file from HotA, and the .json files showing creature traits, and I first saw that AI and fight values are different, maybe something else is different too?

I’m not very sure about this because none of my text editor programs can read the font in which HotA is written(in Russian). So I’m not sure if those are exactly those creatures, also there are some other things I believe to be different. I was looking for Haspid in CRTRAITS.txt, and since I couldn’t read it since the font doesn’t work, then I was looking for the monster that costs 4500 gold and 2 sulfurs, and I couldn’t find such a monster. This confuses me very much. :confused: :unamused:

#3

IIRC I made creatures, mostly by exporting them from HotA data and then Warmonger gave them their abilities.

To see Cyrillic script you need to set Win-1251 encoding. As for creature cost - this was one of things that was changed in 1.2. If you still have 1.0 release then you’ll see some differences.

#4

Well, I just played it, and it says верзия 1.2 in the lower-right corner :confused:
When was that version released?
Oh and by the way, how to set that encoding?

#5

By the way, I think that there is no reason to strictly use HOTA parameters and AI/Fight values in VCMI.
Because VCMI is not HOTA.
HOTA crew balanced these stats only according to standart factions and units. When you add new town to VCMI (Forge, Grove or any other), balance in any way totally changes.
So people bothered by some balance myth will be forced to totally redo all parameters for each towns collection.
For example, Succession Wars parameters are only good for SW. When you will take SW factions and enter them to VCMI, you will notice, that SW factions balance is no more, and SW factions are totally weaker than any of standart factions (in terms of growth, hit points, cost etc).
So if you want balance, you are only one who can make it for your mods configuration.

#6

1st January

That’s heavily depends on text editor you’re using.

BTW - Hota does not uses *.txt files - instead most of their data can be found in encrypted binary HotA.dat. So CrTraits.txt does not contains any HotA-related data.

#7

Ohh, that’s all I need to do? Thank you! :mrgreen:
It seems I found it in Notepad++ which I use for .json files, but I also use TxtEdit for old txt tables like crtraits, and that’s where I need it.

But there is a crtraits.txt in HotA_lng.lod? :astonished:
I checked it now, because I’m not blind when I can change the encoding, so it turns out that file only contains creatures from regular heroes 3, but not from cove. I can’t believe I thought that cove creatures were in there…
I guess there is no way to read the HotA.dat file?

#8

There is no easy way to do this.

First you need to decrypt it. This will give you binary file that you can “read” with hex editor. But this is far from being close to human-readable.
For initial data import I had to write a tool that will do this stuff automatically but I no longer have it - using HotA changelogs to keep vcmi mod up-to-date is much faster.

#9

In siege mode Cove shooters are placed wrongly.
There coordinates should be something like

“towers” :
{
“top” :
{
“tower” : { “x” : 575, “y” : 35 },
“battlement” : { “x” : 575, “y” : 35 },
“creature” : { “x” : 340, “y” : -165 }
},
“keep” :
{
“tower” : { “x” : 727, “y” : 180 },
“battlement” : { “x” : 727, “y” : 180 },
“creature” : { “x” : 518, “y” : -20 }
},
“bottom” :
{
“tower” : { “x” : 630, “y” : 516 },
“battlement” : { “x” : 630, “y” : 516 },
“creature” : { “x” : 395, “y” : 310 }
}
},

#10

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)
#11

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

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

#12

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.

#13

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.

#14

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

#15

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

#16

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.

#17

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!

#18

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

#19

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.

#20

…

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.