A taxonomy of equippable items

No item exists in the game without a corresponding .uti file. Equippable items can be placed on creatures or in placeables or spawned directly into the game via scripting, but the item itself must come first. The appearance of the item is dictated by its type and item variation. In the toolset it looks like this:

Exported as a .uti, it looks more like this:

The numbers in the exported .uti are referencing 2DAs, which are the core framework referenced by the game scripts to determine how things work in the game.

In the case of equippable items, they’re referencing BITM_base (base item) as well as one of the many item variation 2DAs (ItemVariations.xls) based on their type. So this could be clothing_variation.gda, boots_heavy_variation.gda, kite_shield_variation.gda, etc. Before compilation, they’re editable in spreadsheet format and can be found in <game install dir>\tools\source\2DA\

(A note, clothing_variation items are unibody meshes. Gloves and boots can be equipped but won’t show in game. Armor_*_variation items are not unibody. Gloves and boots will appear if equipped, nude hands and feet otherwise. There might be weird clipping or floating if the full armor set is not equipped and the vanilla parts don’t all line up with the new mesh.)

Most 2DAs can be extended by the M2DA (multiple 2DA) format. Rather than overwriting the entire 2DA (which is bad for mod compatibility and can wreck your shit if done improperly), the game scans each M2DA and only adds or overwrites individual lines rather than everything. You set up an M2DA by deleting all the lines you do not want to overwrite, and add a unique file suffix. So armor_light_variation_admiral.gda will add to or overwrite individual lines in the armor_light_variation.gda. Neglecting to add the suffix will override the 2DA entirely. Don’t forget this.

Each line in the 2DA is identified by the ID number in the first column. If you want to add an item variation it must use a unique ID unless you very specifically want to overwrite or replace an existing item. Unfortunately due to a bug in the .uti format, the IDs in the item variation 2DAs are restricted to 1-255. This means mod conflicts between new variations of the same item type can be regrettably common as people accidentally pick the same ID, giving one of the conflicting items the wrong appearance.

Variation conflicts can be resolved by locating the conflicting files and changing the ID in both the .gda and the .uti to a new ID not currently in use.

The item variation 2DAs reference both the mesh model hierarchy (.mmh) and physics (.phy) files based on their file name. They MUST be named identically according to game standards. An example:

hf_cth_antia_0.mmh

The first part is the race and gender of the model. df_, em_, kn_ (kids are agender), etc. If a weapon or shield the prefix is w_. The game will look for the right file automatically when equipped on a character. If it doesn’t find an appropriate .mmh then nothing will display. You’ll end up with a floating head, perhaps, or a character with no feet or no scalp.

The second part, the model type, can be assigned arbitrarily but usually follows some standard conventions for legibility. arm = armor, rob = robes, cth = clothing, glv = gloves, etc.

The third part is a unique identifier for the model subtype (usually identifying the mesh) plus one letter for the model variation. In vanilla for example the commoner clothes come in variations coma through comi, noble clothes noba – nobe, etc. The variations share the same mesh but assigning a unique variation allows them to reference different textures. This part doesn’t have to follow vanilla four letter convention. It can be whatever you wish as long as it’s put in a format the 2DA can recognize. For example ant | a is just as valid as antiva | n.

(Note this doesn’t actually have to reflect what the mesh is named but it’s nice if everything is named similarly for ease of use.)

The last part of the file name (_0, _2, or _3) is the LOD or level of detail. The game will automatically fetch the proper file depending on how close to an object you are standing. For vanilla resources this is done for performance reasons. Higher LOD objects (LOD0) have higher poly meshes and larger texture files. Lower LOD objects, which are further from the camera, are lower poly and have smaller textures (and thus smaller file sizes).

If a lower LOD .mmh for an object isn’t found the game will attempt to apply higher LOD resources to the lower LOD skeleton but this doesn’t always work great. LOD issues in mods can cause a lot of strange visuals that are not usually noticeable on the player character (unless you hold them in place and run away with another party member) but can be very noticeable when applying modded meshes to NPCs. This is mostly caused by virtue of the lower LOD skeletons having fewer bones than the LOD0 skeleton, so the rigging gets jacked up. Hair might float in midair, or distant characters might warp strangely, particularly when animated. If a replacement mod only changed LOD0 then the vanilla mesh and/or texture will “pop” in and out when the LOD changes.

For the these reasons it is a very good idea to rig a modded armor mesh for LOD2 as well as LOD0 (LOD3 is overkill, it doesn’t matter at all) even if you don’t want to reduce your poly count and texture size (since if you don’t supply LOD2 yourself the game will just load the LOD0 resources anyway, so it’s not any LESS resource-efficient). It can be done the exact same way you rigged the mesh to an LOD0 skeleton (assuming it’s not an edit of an existing vanilla mesh… that’s a different story) and takes a hell of a lot less time due to the reduced bone count and lessened need for accuracy with increased camera distance.

Opening up the .mmh in pyGFF you can see where it points to the mesh (.msh) which contains the model vertex data. Further down, it also points to the material object (.mao).

The DAO .mao is in XML format and can be opened in any text editor (in DA2 it needs to be opened in pyGFF). Here it defines the material properties as well as which texture maps are applied to the model.

Once you have ALL of those files together – the textures, the material object .mao, the mesh .msh, the model mesh hierarchy .mmh and physics .phy, the unique item variation .gda, and the item .uti… then you have an object that can be equipped and display properly in game.

Actually getting it into the game is an ENTIRELY different beast.