Hi Tsongo
Let me jump in here and maybe this long, in-depth answer will help future folks looking to customize custom content.
In order for something to display in game (any sort of model: heads, bodies (i.e. armors) boots, items, creatures, weapons) the game needs three things:
- A UT? file (.UTI for items, UTC for creature etc.). This is a data list, sometimes called a blueprint, that essentially gives the specific info about how that item will work in game, often (maybe always?) by referring to certain .2da files. UT? can be edited in the toolset (this is what you are doing when you edit blueprints or instances in the properties window) or with an editor like GFF Editor or TLKEdit.
For getting armors to appear correctly the corresponding UTI file contains four important fields:
- BaseItemType refers to baseitems.2da, which tells the game engine how different things are supposed to work. Armor is 16 and tells the game, among other things, what kind of files with which file-naming conventions it needs to find to display that thing in the game.
- ArmorRulesType. Refers to armorrules.2da which tells the game all the die-rolling info needed for someone wear and use the armor, such as max dex bonus, armor check, weight etc.
- ArmorVisualType. This refers to the armorvisualdata.2da. 0 = clothes, 3 is leather etc, 15 is MP for Morgam Palantir’s custom content (if you have that installed and are using that version of the .2da). This 2da file lists the two-letter codes for each type of armor. It is no problem at all, and quite common in fact, for ArmorRulesType and ArmorVisualType to be different. Like the look of a certain chain mail for your heavy armor wearing cleric. No prob. Set ArmorRulesType to full plate and ArmorVisualType to 4.
- Variation. This number +1 tells the game which model of a given category to use (as said above the file names start with 1 but the game engine starts at 0).
Before moving on to the next thing you need, it’s important to note that the game also needs the race and gender of the creature to wear the armor. The game finds this in either the UTC file for a creature (including NPCs) or, for PCs/companions, in the player.ifo or npcname.ros file found in the save folder. The race refers to appearance.2da, which tells the game what file names to look for for the armor model for a given creature (the HHF EHM, GGF part) for bodies, heads etc. If you look in appearance.2da you can quickly see what races use which armors (for example, in addition to humans, and half elves, aasimars, tieflings and haflings use HH? model, with a factor for scaling them appropriately). If no model exists for that race, the creature will appear in its underwear.
- An .MDB file. This file contains the model (also called “mesh”) info for the item or creature. It’s main content is the list of vertices and faces that make up the 3d shape. You need to use 3d modelling software to modify this shape. A single mdb can contain several mesh packets (a base one, LO ones, which are lower resolution versions of the model used to reduce processing needs when zoomed out (ie fewer faces to display), skeleton info for animation, eyes if it’s a head, hook points (where one mesh like a weapon connects to another mesh like the hand on an armor mesh) and collision boxes). An .MDB also contains “texture” information, which tells the game what image file(s) to use to display the model in game. Think of it like this, the game displays a 3d model, then wraps one or more 2d images around it like wallpaper. More on textures under 3. below.
All of the meshes within a single .mdb must have the same base name and .MDB file names must follow a certain convention. For armors (and heads and gloves and hats and most other things that move) the convention is:
P_Race_VisualType_PartTypeVariation
so a male human full plate armor with variation 17 would be
P_HHM_PF_Body17.mdb
A female aasimar cloth hat variation 232 would be
P_AAF_CL_Helm232
The P comes from baseitems.2da, the HHM from appearance.2da, the PF from armorvisualdata.2da and the number from the Variation line in the UTI file. If any of these is incorrect or does not match, whether in the file name or in the mesh names inside the .mdb file, the thing won’t display and there will be an invisible gap between the character’s head and boots in game. For this reason I recommend using mdbcloner, instead of mdbconfig if you are just quickly copying and renaming mdbs. mdbconfig requires you to manually change the name of each and every mesh packet, giving more opportunity for typos and mistakes.
- .DDS (or .TGA) texture files. These, the stock ones of which the game stores in the folder called “Materials”, are the 2d image files the game wraps around models so the meshes show up as something other than a plasticky looking grey blob. The textures line up on the model using something called UV coordinates which are stored inside the .mdb files. You can’t see or mess with these using just mdbcloner or mdbconfig – you need a 3d modeling program to adjust the UV coordinates. Every .mdb has different UV coords so if you assign a texture file to an .mdb that doesn’t match up it will look like a four-year old’s best effort with water colors . However you can modify textures by “painting within the lines” of the existing texture. Want to add a sigil to the left breast of a plate armor, just use your favorite image editor (photoshop, gimp etc) to open the texture file, figure out which part of it corresponds to the left breast and paint/paste you sigil there. Careful, most image editors don’t work well with .dds (I never have found one that will save alpha channels in one on a Mac) so that’s why you can also use .tga, though they are less compressed and too many could affect performance.
Texture files can have any file name you want, though some require a specific extension (see below). However, it’s good practice to give them the same name as the .mdb so other users know which textures go with which models. There are four kinds of textures, the first two of which are required for all models, the second pair being optional:
- Diffuse is the color scheme to apply to the model (no extension)
- Normal maps tell the game engine how to bounce light off the model (extension _n.dds)
- Tint maps modify/replace the base color in the diffuse map, making it tintable along an rbg scheme; the alpha channel can make things transparent. (extension _t.dds).
- Glow, creates a light effect (extension _i.dds)
So take for example the male plate armor above: P_HHM_PF_Body17. It must have a diffuse and normal map and let’s make it tintable too. Now we could name these:
myawesomeplatemail.dds
totallycoolnormals_n.dds
letstintthisshit_t.dds
As long as the mdb is set to use these, no prob (we set this in mdbcloner or mdbconfig). But it’d be mush easier to keep track of which files to use if we names them:
P_HHM_PF_Body17.dds
P_HHM_PF_Body17_n.dds
P_HHM_PF_Body17_t.dds
So to get this in game I need the following files:
- MyPlate17.uti (again name this whatever you want) with armorvisualtype set to 8 for plate, Variation set to 16 and armorrules set to whatever full plate is.
- an mdb for each race and gender I want to be able to use it. These meshes may be different for different races (female armors have boobs, orcs have broader shoulders, dwarves are short and squat, elves are slender, etc). Name for each must match the naming convention described above. A full set for all races/genders means ten total mdbs (DD?, EE?, GG?, HH?, OO?).
- textures for each of the ten .mdbs. Often you can use the same textures for multiple races/gender, but sometimes the model is different enough to need different textures (like a bare midriff on the female version).
In fact, a lot of the stock game models were just scaled and stretched to look race correct, without changing the number or arrangement of faces in the model, and so they have the same UV coord and so can use the same textures.
So here’s where we get to how to replace/override stock game armors. If I wanted my model P_HHM_PF_Body17 to override stock model P_HHM_CH_Body01, I would use mdbcloner, change the packet name to P_HHM_CH_Body01 and save it as P_HHM_CH_Body01.mdb. Plunk in override along with my textures called P_HHM_PF_Body17. This should be all that is needed. If you change the textures used by the .mdb in mdbcloner to P_HHM_CH_Body01 the game will use the stock game ones and it will be all messed up. You would need to rename your textures to this. Other than now having two sets of textures with the same name but different content (the stock game ones in the zip folders and your custom ones in the override) I don’t see any reason to prefer one method of assigning textures over the other. Just need to make sure the custom mdb is pointing to the custom textures, whatever their file name.
So I hope this barrage helps. It took me years to figure all this out. I’m in the opposite boat to Tsongo, where I started doing custom content, and only recently got into the toolset (Mac guy, right!) so I have lots of similar questions about how to use that, whereas Serene is proof of Tsongo’s toolset skill. In fact, I probably never would have figured most of this out if I hadn’t been on a mac since the toolset would have taken care of a lot of it for me.