Skip to content

Posts from Guide on adding a new model, animation, and creature to HoMMV

No ratings yet — be the first to rate!
In reply to Elu
User Avatar
6 years ago
Auto-translated
Guide to using the new file structure,
which significantly simplifies the modding process.


How can the new structure be used to quickly replace any creature in the game?
Or quickly create a new NCF creature?


This text is intended for relative beginners in modding, but I hope it will also be useful for experienced modders
to understand how to save time and effort by using the new file structure.

Drop the "Z_TestCreature.pak" template into the "data" folder in the game root.

Download the Z_TestCreature.pak template file.

Move the downloaded "Z_TestCreature.pak" file to the "data" folder inside the Heroes of Might and Magic V game folder.
The path will be approximately "C:\Program Files\Nival Interactive\Heroes of Might and Magic V - Tribes of the East\data".
Remember that a ".pak" format file is just a regular archive. It can be opened and edited using WinRAR or WinZip.


Example 1: Replacing any creature in the game with a test visual from "Z_TestCreature.pak,"
or creating a new NCF creature that uses this visual.

(The test visual looks like an ordinary peasant in a yellow shirt.)


Find the "data.pak" archive inside the "data" folder within the Heroes of Might and Magic V game directory.
For starters, let's assume you want to replace the footmen from Haven with the test visual.
Inside the "data.pak" archive, find the file "Footman.xdb" at the path "GameMechanics\Creature\Creatures\Haven\Footman.xdb ".
Extract it from the archive while preserving the folder structure. Then uncheck "Read-only" in the file properties.
Next, inside the "data.pak" archive, find the file "Footman.xdb", but this time at the path "MapObjects\_(AdvMapObjectLink)\Monsters\Haven\Foot man.xdb".
Extract this file from the archive as well, again preserving the folder structure. Then uncheck "Read-only" in its properties.
Drop these two files (preserving the folder structure) into the "Z_TestCreature.pak" archive in the "data" folder.

The entire process is done in four simple steps.
Step 1.
Open the file "GameMechanics\Creature\Creatures\Haven\Footman.xdb " inside the "Z_TestCreature.pak" archive.
Find the lines "MonsterShared" and "Visual"

replace the original paths in them with the paths to the test creature's files.
i.e.
replace the path to "MonsterShared"
/MapObjects/Haven/Footman.(AdvMapMonsterShared).xdb
with
/new_creatures/test_fraction/test_creature/creature.(AdvMapMonsterShared).xdb
and the path to "Visual" from
/GameMechanics/CreatureVisual/Creatures/Haven/Footman.xdb
to
/new_creatures/test_fraction/test_creature/creature.(CreatureVisual).xdb

(these lines can be copied from the peasant file, modified for the needs of the test template,
i.e., the file "GameMechanics\Creature\Creatures\Haven\Peasant.xdb " inside the "Z_TestCreature.pak" archive)

Step 2.
Next, open the file "MapObjects\_(AdvMapObjectLink)\Monsters\Haven\Foot man.xdb" inside the "Z_TestCreature.pak" archive.
In the third line, replace the path to "AdvMapMonsterShared"
i.e.
replace
/MapObjects/Haven/Footman.(AdvMapMonsterShared).xdb
with
/new_creatures/test_fraction/test_creature/creature.(AdvMapMonsterShared).xdb


Step 3.
Delete from the "Z_TestCreature.pak" archive
the file "GameMechanics\Creature\Creatures\Haven\Peasant.xdb "
and the file "MapObjects\_(AdvMapObjectLink)\Monsters\Haven\Peas ant.xdb"
so that this same test visual doesn't replace the peasant along with the footman.

Step 4.
Next, inside the "Z_TestCreature.pak" archive, find the file
"/new_creatures/test_fraction/test_creature/creature.(AdvMapMonsterShared).xdb"
in it, replace the creature's ID line with the footman's ID.
i.e.
replace CREATURE_PEASANT
with CREATURE_FOOTMAN


Now the test visual (peasant in a yellow shirt) will replace the footman in the game.

How to replace a creature other than footmen?
By analogy with what was described in the main text of Example 1.
You simply need to copy from the "data.pak" archive,
from the folders "GameMechanics\Creature\Creatures" and "MapObjects\_(AdvMapObjectLink)\Monsters",
the files corresponding to the creature you want to replace instead of the footman's files.
The ID of your creature, which needs to be entered instead of "CREATURE_PEASANT" in the "creature.(AdvMapMonsterShared).xdb" file,
can be found by searching through the files in the "GameMechanics\Creature\Creatures" folder.
Or Google it; this ID is used in script commands, so there is information about this online.

How to understand which files correspond to which creature? Use your head.
If you struggle with English, you can use a translator.

How to add an NCF creature?
By analogy with what was described in the main text of Example 1.
Only replace the paths in the files corresponding to the NCF creature.
And of course, you must have the NCF core installed.

How to change a creature's description and name?
Replace the text in the files.
for the name
"/new_creatures/test_fraction/test_creature/icon_text/name.txt"
for the description
"/new_creatures/test_fraction/test_creature/icon_text/description.txt"


How to change a creature's icon?
Edit or replace the file
"/new_creatures/test_fraction/test_creature/icon_text/icon.(Texture).dds"

.dds files can be edited via Adobe Photoshop with an installed dds plugin.

Here are the more or less optimal settings for saving dds for HoMMV.

For creature icons and other interface elements, it is better to disable MIP maps.
For textures that will be used on a model, MIP maps must be enabled.

psatkha wrote a good guide on editing icons.


How to change a creature's game stats, add a spell, teleport, etc.?
Game stats are written in the file (using the footman as an example) "GameMechanics\Creature\Creatures\Haven\Footman.xdb ".
By analogy, copy and edit the stats file of the creature you are modifying/adding.

For example, to make a creature a ranged attacker, you need to enter the number of shots in the "Shots" column


And this is how a spell assigned to a creature looks, using dwarf mages as an example.


I won't have the strength to explain what every digit and parameter means in the creature files.
Therefore, explore this yourself by examining the original creature stat files
located in the "GameMechanics\Creature\Creatures" folder.
Or Google additional information online (it exists, and there is a lot of it).

There is only one small nuance: teleportation.
If you want your creature to use teleport when moving (this does not automatically give it the "flying creature" ability),
then you need to edit the file "/new_creatures/test_fraction/test_creature/creature.(CreatureVisual).xdb"
Specifically, the "TeleportingMove" section. In "Use", replace "False" with "True".

And in the lines below, you can optionally choose a teleport effect.
Once you have made the creature teleporting, it will use "moveStart" and "moveEnd" animations instead of "move".


How to change the camera position in the in-game creature view menu?
To do this, you need to copy from the "data.pak" archive into your own archive the file responsible for the selected creature's camera.
For example, for the peasant, it is "Cameras/Interface/HireCreatures/Peasant.xdb", already edited in the "Z_TestCreature.pak" archive.
Editing the camera is very tedious because you have to edit numeric values, and the result can only be viewed in-game.
Therefore, it is often faster to copy the contents of a more suitable camera file from another creature into your creature's camera file.

For example, the peasant in the "Z_TestCreature.pak" template actually uses the footmen's camera.


How to add an effect to a creature's animation?
The "Z_TestCreature.pak" archive already contains a test effect in the folder "/new_creatures/test_fraction/test_creature/animset/effects/".
(These are glowing purple eyes, from the skeleton alt-grade)
If you want to test this effect, simply enter the path to the effect into your animation file, for example, in the file
"/new_creatures/test_fraction/test_creature/animset/idle00.(BasicSkelAnim).xdb"
in the "Effect" line: href="effects/idle00.(Effect).xdb#xpointer(/Effect)"


Now, in-game, the peasant in the yellow shirt will have glowing purple eyes.

Note that the "GlueToNamedBon" line
in the file "/new_creatures/test_fraction/test_creature/animset/effects/head_bone.(ParticleInstance).xdb"
determines which bone of the model's skeleton the effect will be "glued" to.

In the past, modders often used effects to "hang" model elements (helmets, swords, etc.) on a creature.
This method can still be useful for solving various specific tasks.
(for example, when you need a model element to appear or disappear only in one animation).

You will have to figure out how to create your own effect independently;
this can be done by studying the example from "Z_TestCreature.pak", examples from the game, and examples from various mods.




Example 2: The same thing, but using a new imported model.
(for example, a model from Heroes VII)

Complete the full process of adding a model as described in the guide for importing models, skeletons, and animations.
Follow the process described above in Example 1.
All set.


Example 3: The same thing, but using a "recolored" model based on a Heroes V model.

What is described in Example 3 only makes sense if you want to replace peasants with recolored knights, for example,
or create an NCF creature from recolored knights.
If you just want to recolor the knights and leave them in their place,
the most optimal way is simply to find and recolor their texture.


Follow the process described above in Example 1: replace the desired creature with a test visual (peasant in a yellow shirt),
or create an NCF creature with this visual.


Next, you'll need to figure out a bit about what is located where in the in-game archives.
But I will try to explain how to do this more or less easily.

To create a recolored version of a creature from the original game,
you need to find three groups of files in the original game's "data.pak" archive.
1 model and skeleton xdb files.
2 texture dds files.
3 animset xdb file and animation xdb files.

You can find where these files are located using the map editor.
Open a map, place a creature on the map, and select it.
In the side menu, click on the "Shared" tab, then click the button with three dots.


A new window will open.
In the left half of the window, you can see how the
"AdvMapMonsterShared" file (global map shader) for the selected creature is located in the folder structure.
In the right half of the window, you see the contents of the "AdvMapMonsterShared" file.
Through the contents of this file, you can find paths to the model and textures, animset, and animations.
The "AnimSet" line refers to an animset xdb file, which in turn contains links to animation files.
The "Model" line refers to a model xdb file containing links to skeleton geometry and material files.
Material files, in turn, refer to texture files.
Files specified in these lines can be viewed by selecting the line and clicking the button with three dots.


Important: about lod
In (AdvMapMonsterShared), a low-polygon (blocky) version of the model for the global map is often specified, i.e., lod.
For your mod template, you need a higher-polygon model;
most often, you can simply open the link to the model and select the high-polygon model from the left menu,
which is in the same folder, but if you are unlucky, the high-polygon model may be anywhere and will have to be searched for.




Navigating through your creature's file structure in the editor, find and remember the path to:
1 geometry and skeleton xdb files.
Important: If the creature has no geometry or skeleton xdb files.
Sometimes developers embed geometry and skeleton files inside the model xdb file.
In that case, you need to remember the path to the model xdb file.

2 texture dds files.
3 animset xdb and animation xdb files.
Now find these files in the "data.pak" archive and copy them.


Now we finally form the template for your recolor mod.
1 Rename the model and skeleton xdb files to "creature-Geom.xdb" and "creature-Skel.xdb" respectively.
Drop them into the mod template archive in the folder with your creature.
Important: If the creature had no geometry or skeleton xdb files.
You need to copy the model xdb file entirely.
Rename it to "creature.(Model).xdb" and drop it into the mod template archive in the folder with your creature.

An important nuance: in this case, you must change the old material paths in this file to new ones:
href="material/material1.(Material).xdb#xpointer(/Material)".


2 Rename dds files to "texture1.(Texture).dds", "texture2.(Texture).dds", etc.
Drop them into the mod template archive in the folder with your creature, in the "material" subfolder.
Important: If your model has more than one texture.
It's simple. Open the creature.(Model).xdb file located in your creature's folder.
Edit the material links so that the correct materials are displayed in the correct order.

This is easy because all materials in this structure have the same names except for the number.
Just replace the number in the material name.
If the model has more than two materials, you need to add one line for each new material
with a correct link to its location.


3 In the mod template archive, in your creature's folder, delete everything from the "animset" subfolder to avoid confusion and conflicts.
Rename your animset file to "creature.(AnimSet).xdb", and edit this file so that animation paths refer to the local folder.
i.e.
for example, instead of
href="/_(BasicSkelAnim)/Creatures/Haven/Angel/idle00.(BasicSkelAnim).xdb#xpointer(/BasicSkelAnim)"
it should be
href="idle00.(BasicSkelAnim).xdb#xpointer(/BasicSkelAnim)"
Collect the animation files; they do not need to be renamed.
Drop the renamed animset and animation files into the mod template archive, in your creature's folder, in the "animset" subfolder.

In general terms, that's it. Now you have a ready-made creature template separated from the original.

Now you just need to take and recolor it.
To do this, edit the files "texture1.(Texture).dds", "texture2.(Texture).dds", etc.
which you placed in the "material" subfolder of your creature's folder in the mod template archive.

.dds files can be edited via Adobe Photoshop with an installed dds plugin.

Here are the more or less optimal settings for saving dds for HoMMV.





Important: How to create a unique file structure instead of the test "/test_fraction/test_creature/"
and clean your finished mod of unnecessary test debris?

This is seemingly optional, but a very important stage.
In principle, if you don't do it, your mod will still work, but there will be a conflict between two such mods.

To avoid conflicts and just to keep everything neat and beautiful:

1 Change the name of the "Z_TestCreature.pak" archive to something unique (no Cyrillic),
for example, for black guards I would use the name "H7DarkGuard.pak".

2 Inside your archive, change the names of the folders "/test_fraction/test_creature/" to "/faction name/creature name/"
again, using the black guards as an example: "/neutral/H7DarkGuard/".

3 Update the path to your creature's visual in the files of the replaced creature.
Using the knight as an example, these are the files:
"GameMechanics\Creature\Creatures\Haven\Footman.xdb "
"GameMechanics\Creature\Creatures\Haven\Footman.xdb "
in them "/test_fraction/test_creature/" must be replaced with the new path "/neutral/H7DarkGuard/".
(Obviously, it would have been more convenient to rename the folders first and then specify the path;
this guide did it differently only to introduce beginners to the information step-by-step.)

That's it; your mod now conflicts with nothing and can be safely published.

A few words about cleaning the archive of extra files.
Inside the archive, from your creature's folder (formerly "/test_fraction/test_creature/"), you can:
Delete the file "Cameras/Interface/HireCreatures/Peasant.xdb".
(this is the edited test "view menu camera" for the peasant)
delete the "shot" folder if your creature is not an archer.
(to be sure, you can also delete the path to the shot "href="shot/creature_shot.(Shot).xdb#xpointer(/Shot)"
from the file "creature.(CreatureVisual).xdb")
delete the "effects" folder from the "animset" folder if your creature has no animation effects.
You can clean up other small things, but it's not really worth the time;
I have already pointed out the main potentially redundant files that would be noticeable above.



I strongly recommend reading the point below if you are a "seasoned" modder.
If you are a beginner interested in how everything is structured, this may also interest you.
Why should one use the structure I propose rather than the "as in the original game" structure?

A simple example.
In the structure I propose, the main creature files are located like this:
Monster shader
"new_creatures\test_fraction\test_creature\creature .(AdvMapMonsterShared).xdb"
Creature visual
"new_creatures\test_fraction\test_creature\creature .(CreatureVisual).xdb"
Model
"new_creatures\test_fraction\test_creature\creature .(Model).xdb"
Material
"new_creatures\test_fraction\test_creature\material \material1.(Material).xdb"
Texture
"new_creatures\test_fraction\test_creature\material \texture1.(Texture).xdb"
Animset
"new_creatures\test_fraction\test_creature\animset\ creature.(AnimSet).xdb"
One of the animations
"new_creatures\test_fraction\test_creature\animset\ idle00.xdb"
As you can see, the path is roughly the same everywhere;
all important files are grouped inside one folder as much as possible.
This structure can be used repeatedly; it is maximally universal.
You only need to copy and rename the "test_creature" folder, and you have a full template for a new creature.

For comparison, this is how the peasant's files are located in the original game:
Monster shader
"/MapObjects/Haven/Peasant.(AdvMapMonsterShared).xdb#xpointer(/AdvMapMonsterShared)"
Creature visual
"/GameMechanics/CreatureVisual/Creatures/Haven/Peasant.xdb#xpointer(/CreatureVisual)"
Model
"_(Model)\Creatures\Haven\Peasant.(Model)"
Material
"_(Material)\auto-imported\Grass\Stuff\Log\auto-imported\Creatures\Haven\Peasant\Peasant_lambert.( Material)"
Texture
"Textures\auto-imported_______320\dev\Test\TMPcharacters\Peasant\ Peasant.tga"
Animset
"_(AnimSet)\Creatures\Haven\Peasant-arena.(AnimSet)"
One of the animations
"_(BasicSkelAnim)\Creatures\Haven\Peasant\idle00.(B asicSkelAnim)"
Such a file arrangement is not universal at all and can vary greatly from creature to creature.
Finding source files without an editor is often fundamentally impossible, as it's not obvious that the creature's texture
should be searched for somewhere along the path "auto-imported_______320\dev\Test\TMPcharacters".
As you can see, the spread is quite large, and to collect all these source files, you have to run around folders a lot.
In this specific case, you'd first have to "copy\paste\rename" files seven times,
plus add another 5-8 for animations (which also need renaming), plus every material and texture;
in short, it's a lot of redundant, tedious, and unnecessary work.

Meanwhile, with the grouped structure I propose, all source files will be ready in one "copy\paste\rename",
or at most two "renames" (if you are creating a faction you didn't have before).
With this new structure, you only need to copy the "test_creature" folder located at "new_creatures\test_fraction\test_creature"
to the path "new_creatures\(faction name in Latin)" and rename the faction and creature as you wish.

An important nuance: many copied files inside the renamed "test_creature" folder won't need to be edited at all
(files refer to each other within the folder, regardless of what that folder is called or where it is located).
In the case of copying original game files, you would have to edit every copied file
and most of the links inside it.

In short, compare these two methods and decide which one is more convenient for you.
But my personal opinion is that repeatedly copying a structure "as in the original game"
(or rather not a structure, but structures, because they are constantly different)
is pure masochism—unnecessary and meaningless work.

Why is there such a mess in the game files?
It's a terrible mess, don't even argue. The question is: are the developers that bad? Of course not. Not at all.
First, the developers focused on making a working game first, not a beautiful and convenient file structure.
Second, the game was made by far more than two or three people, and the structure clearly formed during development;
there was no time to fit everything into one format later.
Third, the concept of many game elements changed significantly (this can be learned from interviews with developers),
and this left its mark on the file structure.
Fourth, and most importantly, the developers likely used some tooling tailored for working
with such a structure, so the general mess was not critical for them.
(i.e., I mean some script that automatically created all necessary files and wrote current paths).
We don't have these tools; therefore, it seems to me that we should maximize systematization and simplify the process of creating files "by hand".
I see no reason why one should arrange files "as in the original game",
except, of course, for those files like "GameMechanics\Creature\Creatures\Haven\Peasant.xdb " which for some reasons are inconvenient to group into one folder.
User Avatar
6 years ago
Auto-translated
Except for files like "GameMechanics\Creature\Creatures\Haven\Peasant.xdb," which are hardcoded.
These paths can also be changed, but you'll have to rewrite them in Creatures.xdb. Or are you talking about something else?

Overall, it's a good idea, but I think an ideal system would be one where the developers have a fully structured approach. That is, the paths to all creature resources are the same and differ only in the root folders.
In reply to Gerter
User Avatar
6 years ago
Auto-translated
Gerter
these paths can also be changed, but you'll have to rewrite them in Creatures.xdb. Or are you talking about something else?

Overall, it's a good idea, but I think the ideal system would be the one used by the developers, if it were fully structured. That is, the paths to all creature resources are the same and differ only in the root folders.

Yes, I'm talking about them.
By the way, I didn't know, but I guessed that the paths to these files can also be changed in some large root file.
But this is not important because it is potentially conflicting; with each new creature, you need to edit a large file, and two mods where it is corrected will conflict with each other.


The structure, as with the developers, is not convenient for manual copying; you need to go into each of these folders (and there is a long path to each) and copy each file.
As I suggest, all important files are in one folder and reference each other.
You just take and copy, and most of the structural files are already ready.

A simple example.
If, for example, the same file with visuals was in the original folder as with the developers, then for the mod, it would be necessary to find it, copy it, and correct the paths inside that reference the icon, the character, the name and description of the creature, and the attack animation. And this is just one file.
In my version, you just copy the folder with the creature's files entirely, and that's it; the file with the visuals is already ready inside, and no paths need to be changed because they reference locally within the folder, and it doesn't matter what this folder is called.
In short, the idea was to create not a "beautiful" structure, but a neat and convenient one for quickly creating modifications.

I really wanted to convey this idea because it literally saved me hours of tedious, painstaking work of entering and checking the correct paths and copying the correct files.

Just try to quickly create a mod according to my scheme. The basic files will be ready in a minute. Can you prepare the basic files in the same amount of time in the structure that the developers use?
It would take me from half an hour to an hour and a half. While you find everything, while you copy, while you change the paths. Then you will definitely make a mistake somewhere, while you find where, etc. Why waste time on this if you can do the same thing in a minute?
In reply to zahar0z
User Avatar
6 years ago
Auto-translated
zahar0z
Yes, I'm talking about that.
By the way, I didn't know, but I suspected that the paths to these files could also be changed in some large root file.
But this is not important because it is potentially conflicting; with each new creature, you need to edit a large file, and two mods that have it corrected will conflict with each other.


The structure, as with the developers, is inconvenient for manual copying; you need to go into each of these folders (and there is a very long path to each) and copy each file.
As I suggest, all important files are in one folder and reference each other.
You just take and copy, and most of the structural files are already ready.

A simple example.
If, for example, the same file with visuals was in the original folder as with the developers, then for the mod, you would need to find it, copy it, and edit the paths inside that reference the icon, the character, the name and description of the creature, and the projectile. And this is just one file.
In my version, you just copy the folder with the creature's files entirely, and that's it; the file with the visuals is already ready inside, and no paths need to be changed because they reference locally within the folder, and it doesn't matter what this folder is called.
In short, the idea was to make not a "beautiful" structure, but a neat and convenient one for quickly creating modifications.

I really wanted to convey this idea because it literally saved me hours of tedious, painstaking work on entering and checking the correct paths and copying the correct files.

Just try to quickly create a mod using my scheme. The basic files will be ready in a minute. Can you prepare the basic files in the same amount of time in the structure that the developers use?
It would take me from half an hour to an hour and a half. While you find everything, while you copy, while you change the paths. Then you will definitely make a mistake somewhere, and then you will find where, etc. Why waste time on this if you can do the same thing in a minute?

Well, for example, if you use an editor to create or edit resources, then first of all, the type of resource is specified, so I think that distributing resources in a mod precisely by type is better, at least in terms of clarity. When editing manually, of course, there are inconveniences, but this is due to the lack of a common structure in the resources used by the developers. If all the creature resources were arranged in the form of: "resource_name/..path../creature_name.xdb#xpointer(/resource_name)", then there would be no problem as such
In reply to Gerter
User Avatar
6 years ago
Auto-translated
Even if you use an editor, you'll still need significantly more than a minute to create all the files and specify all the paths. Why waste time and nerves on this when you can do everything "in two clicks"? Just to make it "like the developers did"? I don't understand why you would want to imitate this mess. I would understand if there was no other way, but there is. Seriously, I don't get it. There's an option to copy 1 folder, along with the files, rename it, make some adjustments, and add the missing elements, and the xdb part of the mod will be ready in about 5 minutes. Why, instead, copy (or create through an editor) 7-10 files scattered throughout the game archive, which are then very difficult to find without an editor, and to make them appear in the editor on another map, they need to be specified separately. In each of the 7-10 files, you need to specify at least 1 path, and more often much more (and 7-10 files is still if there are no animations, effects, additional textures, and other joys of life). Am I missing something? How can this masochism be more convenient than simply taking and copying just one folder with 90% ready content?

Added after 14 minutes
The clarity in the new structure is also more than okay. This issue is solved by the fact that inside the general folder with the creature, each xdb file has its type indicated in the name. It is immediately clear what the file is and what it is responsible for.

In the original game files, this is not done everywhere. The file Footman.xdb can be anything. And you can find an xdb file responsible for the model (without indicating that it is specifically a model) next to textures and animations (also without indication), and all this good stuff will be piled together in a "characters" folder, which is supposed to contain characters.

Actually, a good question is, why did the developers eventually (and this happened in the expansions) abandon their old structure and try to put the files of new creatures as much as possible in one folder? Isn't it because they realized that the old structure simply wastes development time and everything can be done more efficiently?

Added after 19 minutes
I didn't come up with this idea out of nowhere. I must have noticed at some point that it's easier to copy creature files from an expansion (because they are mainly concentrated in a couple of folders) for a mod template than from the original game (because these files are scattered throughout the archive). Then I wondered if it was possible to create a universal, maximally optimized template based on this principle. And it turned out that it is possible.
User Avatar
6 years ago
Auto-translated
Well, that’s how the developers have it – everything directly related to the model (geometry, materials, textures) is grouped together in one place with a clear designation like “name.(Model).xdb”. Things related to animation are in another place, again with clear designations like .(BasicSkelAnim) and so on. Essentially, it’s the same division, but broken down into logical groups. There’s no dumping everything into one pile anywhere.

What I’m getting at is this: my opinion (and the game’s logic supports this) is that a game resource is tied to its type, not to a specific object. The current developer system is bad because it’s not uniform; the system of dumping everything into one pile is bad (it seems bad to me) because it violates the basic concept of distributing game resources. But that’s just my opinion, of course; I do things the way that’s convenient for me. And I definitely agree that a unified system is needed in these areas.
In reply to Gerter
User Avatar
6 years ago
Auto-translated
Gerter
Essentially, it's the same division, but broken down into logical groups. There's no dumping everything into one pile anywhere.
These aren't logical groups; they're different folders with very long, distinct root paths. There's more grouping of files (apparently, the developers themselves realized over time that this was more convenient). Compare the files of, say, a light creature, i.e., a creature from the original game (scattered throughout the archive), and, for example, Orc creatures (for Orcs, the model, geometry, skeleton, animset, animations, materials, textures, and character, i.e., most of the creature's files, will be in one folder somewhere in the characters; there's no point in arguing here; just take a look).

Added 9 minutes later
Gerter
The system of dumping everything into one pile is bad (it seems bad to me) because it violates the main concept of distributing game resources.
What I don't understand is why violating the main concept is bad in your opinion. If the concept is flawed and the developers themselves eventually abandoned it in favor of a more convenient one that doesn't waste time unnecessarily.

But, as you rightly pointed out, everyone has the right to do what is convenient for them. Sorry if I'm being too insistent on my approach or somehow pressuring you; I didn't mean to create negativity; I just think this approach has an objective advantage, i.e., reducing the time spent on routine file copying.
Maybe later, just for a test, try it once, do it according to my scheme; maybe you'll find it more convenient too.

I just find it very difficult to understand why someone would choose to do 20+ actions when they can achieve the same result by doing just one.
In reply to zahar0z
User Avatar
6 years ago
Auto-translated
zahar0z
These aren't logical groups, but rather different folders with very long and distinct root paths. There's a greater grouping of files (apparently, the developers themselves realized over time that this is more convenient). Compare the files of, say, a knight, i.e., creatures from the original game (scattered throughout the archive), and, for example, the creatures of the orcs (for the orcs, the model, geometry, skeleton, animset, animations, materials, textures, and character, i.e., most of the creature's files, will be in one folder somewhere in the characters; there's no point in arguing, just take a look).

Added 9 minutes later
What I can't understand is why deviating from the original concept is, in your opinion, a bad thing. If the concept was flawed, and even the developers themselves eventually abandoned it in favor of a more convenient one that doesn't waste time unnecessarily.

But, as you rightly pointed out, everyone has the right to do what is convenient for them. Sorry if I'm too insistent on my approach or somehow pressuring you; I didn't mean to create negativity. I just think that this approach has an objective advantage, i.e., it reduces the time spent on routine file copying.
Maybe later, just for a test, try it once, do it according to my scheme; maybe you'll find it more convenient too.

I just find it very difficult to understand why someone would choose to do 20+ actions when they can achieve the same result with just one.

The Nival employees who started working on this around the time of "Orcs" were no longer there, and the new employees did it differently – essentially in one place. Who knows what the previous team was thinking, but this kind of thing was also seen in their other (earlier) projects. It's clear that they had their own convenient SDK, which they naturally didn't share, but some of its functionality was included in the editor; if you remember, it wasn't there initially. And they had this saying that the tools (read: SDK) they used were too complex for users! But we're supposedly working on a user-friendly map editor that will be as convenient and functional as the ones in Heroes 3 and 4!

P.S. Creating your "template"/"dummy" is very cool; by the way, my approach also includes a certain standard; I just don't like reinventing the wheel every time! ;)
In reply to psatkha
User Avatar
6 years ago
Auto-translated
psatkha
The Nival employees who started working on this around the time of "Orcs" were no longer there, and the new employees did it differently – essentially in one place...
No, the trend of grouping files and ignoring the originally intended structure appeared even in the expansion with the dwarves. It periodically appears in some files of the original game. In "Orcs," it was simply done as a standard practice, for almost everything.
psatkha
it's clear that they had their own convenient SDK, which they naturally didn't share, but they included some of its functionality in the editor; if you remember, it wasn't there initially... and they had this phrase that the toolkit (read: SDK) they used was too complex for users! But we're supposedly working on a user-friendly map editor that will be convenient and no less functional than in Heroes 3 and 4!
Absolutely. I'm saying the same thing. The structure that was originally conceived is not designed for human processing and convenience. It's a machine structure created by a program. Speaking of the SDK, there's a suspicion that it was simply flawed or unfinished, which is why they didn't share it (or rather, they shared a very cut-down version). Although, who knows what they had.
The Nival guys are great; it's not right to criticize them for the mess in the files. They had a different goal: to create a working game.
Moreover, as I understand it, Ubisoft was constantly interfering with the development with petty, stupid, but time-consuming changes.
I remember a text about Winnie the Pooh from one of Nival's employees. He sadly joked that in Heroes 5, during development,
each hero had their name changed about five times at Ubisoft's behest.
psatkha
Creating your "dummy" is very cool; by the way, my creations also have a certain standard; I just don't like reinventing the wheel every time! ;)

I'm very glad that you agree with me about the wheel.
I suspected that every modder who added a large number of creatures to the game would eventually think about optimizing performance and create their own equivalent of what I posted above.

I didn't invent anything fundamentally new; I just tried to create a template that is convenient for everyone.

In the future, I think I'll create a similar template, but not for a creature, but for a hero. Will anyone find it useful?

Added 28 minutes ago
P.S. If it's not too much trouble, could someone write something here so that I can then create a separate post with information, the link to which I can put in the header.
In reply to zahar0z
User Avatar
6 years ago
Auto-translated
zahar0z
In the future, I think I'll create a similar template, but not for a creature, but for a hero. Will it be useful to anyone?

Of course! I’ll repeat myself again, but people who I mentioned earlier are actively working on NHF – there is plenty of room for activity, so in terms of visuals, a "template" is definitely needed; I would even say that for those who didn't like NHF, but who appreciate the unique appearance of heroes (relatively speaking, but they aren't all identical as per the standard), the UVH mod is just what they need. Perhaps someone will eventually complete the task of replacing all the standard heroes with new ones; for example, this modification, xHeroReplacer by comrade Manulli, is already moving in that direction!
In reply to psatkha
User Avatar
6 years ago
Auto-translated
IMPORTANT: How to adapt and "fix" movement animation from M&MHVII for HoMMV?

You cannot simply take the movement animation from Heroes 7 and import it into Heroes 5.
"insert Boromir meme here"
If it is not edited beforehand, it will "skip" in-game, meaning it will jump from place to place.

Why does this even happen?
Movement animation in Heroes 7, as in most games, is a looped "in-place" motion.
In Heroes 5, for some strange reason, this is not the case.
In HoMMV, a creature's movement animation moves slightly forward relative to its starting point during one cycle.
The game handles all of this in its own clever way.



Now I will explain in detail how to fix this problem.

Open your creature file that has been prepared for animation import.


IMPORTANT: In 3ds Max, meters must be set in the unit settings.
Click "customize"=>"units setup".
In the window that appears, select "Metric" and choose "Meters" from the drop-down list, then click "ok".


Import your creature's "Move" animation by double-clicking the "Move" line in the animation import window of the "ActorX Import" script.
Stop the animation by clicking the stop button on the animation control panel.

Click the "Auto Key" button in the corner of the screen. A red frame will appear around the viewport.
You have entered "Auto Key" mode (automatic keyframe creation mode).
Select our "Global" bone to create the first keyframe for it.


The animation slider should be on frame zero of the timeline; if not,
move it manually by simply left-clicking and dragging it.
Now, with the "Global" bone selected, click the large button with the plus sign and the key.
Note that a new keyframe indicator has appeared on the first frame of the timeline.


Now move the timeline slider to the last frame of the animation; for me, it is 28.
And move the "Global" bone to an exact negative value on the "Y" coordinate.
I suggest using "-2.0".
(for some animations from Heroes 7, "-3.0" is more suitable)


Your animation is now adapted for Heroes 5.
Next, export it to .fbx and follow the steps from 2.4 to 3.1 in the main Manuals regarding model and animation import.
With the correction that you are adding "move" animation instead of "idle".


After this, the movement animation will likely still have jumps in-game,
but these must now be corrected in the xdb files.

Open your mod template and, in the creature's animations folder
("new_creatures\test_fraction\test_creature\animset"),
open the "move.(BasicSkelAnim).xdb" animation file, where you entered the code name of your exported movement animation.



You need to edit the "MovementSpeed" parameter.


Previously, I had to enter it blindly and test it in-game by eye;
this process was agonizing and could stretch for half an hour to an hour.


But then Frozensoull and I created a formula for you to calculate the "MovementSpeed" parameter.
And slightly later, vova2112 created an even better formula, which I provide below.

"meters" : ("frames" : 30)="MovementSpeed"
where "meters" is the value we moved the "Global" bone by,
in meters (without the minus sign, naturally),
and "frames" is the total number of frames of your animation in 3ds Max
(they are divided by 30 because that is the Max FPS; if using frames from Maya, they must be divided by 24)



Let's test this with a Black Guard example.
Its movement animation cycle lasts 28 frames.
I moved it in Max by -2 meters.

it comes out to 2 : (28 : 30)= 2.14285714286

"2.14285714286" is the desired "MovementSpeed".
Enter it into the xdb file. Sometimes you may need to round it to 7-8 decimal places.

That's it. Now the movement animation should work normally.

Some very small jumps are possible, but those will have to be corrected manually "by eye".

The speed of the movement animation, as well as the speed of any other animation,
can be edited via the "SpeedFactor" parameter in the animation xdb file.
Editing "SpeedFactor" in this case does not create any bugs or jumps,
as it likely changes the "MovementSpeed" proportionally in-game.


A texture or part of it is displayed incorrectly in-game. How to fix?

Sometimes, models from 7 have a slightly shifted UV map.
This is not an issue for modern engines, but complications arise when importing into HoMMV.



Fixing this is very simple.
Attention: the actions described below must be performed on the model before the export/import stage to smd format.
i.e., right before step 1.4


With the model selected, open the modifier list and add the "Unwrap UVW" modifier.
To find this modifier quickly in the list, you can press the "u" key after the list opens.


Now, in the modifier parameters, click the "Open UV Editor ..." button.
The "Edit UVWs" window will appear; here you can edit your model's map.
What exactly is this "map"?
A map (UV map) is a specific "chart" that allows your model—a 3D object—
to understand exactly how to project your texture—a 2D plane—onto itself.

In the "Edit UVWs" window, use a selection box to select the map elements that have "popped out" beyond the main square.
Then move them to where they should be located.
In this case, using an orc as an example, you will need to move it by "-1" on the "u" axis.
This can be done manually or simply by typing the value in the field below.


If you did everything correctly, the map elements should now be inside the main field.

Having finished the process, close the "Edit UVWs" window and continue with the main manual, exporting the file to smd.
After these manipulations, there should be no texture problems in-game.


On some elements of the model, the binding breaks; when animations play, they stick out crookedly. How to fix?

After the export/import stage to .smd format, the skeleton binding may fail on some model elements.
This is unnoticeable when the model is in its base pose but clearly visible during animation playback.


The easiest way to fix this problem is by merging fragmented vertices.

Important: for the "magic" described below to work and not ruin your model, meters must be set in the 3ds Max unit settings
(or even better, centimeters or millimeters).
Click "customize"=>"units setup".
In the window that appears, select "Metric" and choose "Meters" from the drop-down list, then click "ok".


Next.
With the model selected, click on the "Editable Poly" modifier
(it should be on your model after importing the smd file).
Enter vertex editing mode.
Select all vertices of your model using "ctrl"+"a".
In the "Edit Vertices" section, click the button next to "Weld".
A small panel with modifier settings will appear.
In it, you should select the minimum available value "0.01".
Then click the checkmark.


Afterward, check if the problem was fixed by playing the animation.

You can also fix this problem by manually editing the skin modifier.
Through this modifier, new elements can be bound to the skeleton.
Information on how to work with this modifier can easily be found independently online.


The model I am converting has more than one texture. What should I do?

Use your head.
Just import the smd model twice.
In "Editable Poly" mode, cut everything related to the second texture from one copy, and everything related to the first from the other.

Most likely, materials will be separated by ID, so to avoid selecting elements manually,
you can switch between materials in the "Polygon: Material IDs" section via the "Select ID" button,
after entering the ID number in the adjacent window.


Have some mercy on me; I will not explain this part in detail. There is plenty of available information on working with Max online, and I have already spent more than half a month on this manual, which some
still find very difficult.

I'll put it this way:
If you are too lazy to figure things out and if you read the text carelessly, any
even the simplest manual will be too difficult for you.


Problem of disappearing polygons when importing a model into Heroes 5.
footman described it in general terms

User Avatar
6 years ago
Auto-translated
Interesting topic. Maybe I'll get inspired and add something from The Witcher to Heroes 5.
In reply to Esto100nec1
User Avatar
6 years ago
Auto-translated
Thank you, I hope this text will be useful to someone. Yesterday, I made significant updates to the guide. I checked and fixed the last minor details. I described in detail the process of adjusting the movement animation. The process of adjusting the movement has been automated using a formula that we calculated with FrozenSoul. It was quite challenging. Now, the entire text is completely ready. All that remains is to translate it into English, but I will do that later.
In reply to zahar0z
User Avatar
6 years ago
Auto-translated
Updated the manual; additionally described some possible problems and how to solve them.

New information can be found in this post
User Avatar
6 years ago
Auto-translated
Regarding models with offset textures, it's quite simple to change the texture mapping type in the XDB file from CLAMP to WRAP. I don't know the difference between these texture mapping types, but this issue only occurs with CLAMP mapping.

Statistics

Welcome our newest member: recijeb

Users Online 2 users 1293 guests