Replacing armours?

just to be clear: with file you meant folder, right? as far as i know that’s not how the engine reads the override folder. you can have subfolders to store different files, but in the end it doesn’t really matter. it’s just for your convienience.

perhaps that’s why you have issues with those files sometimes? it’s best practice to name the mesh (the packet of the .mdb) identical to the file. if it’s really needed? i don’t know. i’m just imitating obsidian here :smiley:

1 Like

Semper… Yes there are two folders named exactly the same as the ones in the program files data folder ( NWN2 models and materials ). I’ve used it for years like that so I know where all the mdbs and dds things are which are separate from whole haks.

The armour came out wrong regardless of whether the dds files were named the same as the mdb, but it worked when they were not named the same but in a folder called bronze armour from a hak that had nothing to do with what I was doing.

In the future I’ll make another folder called “my armour swap” and put them in there and if it goes wrong then I’ll just leave them in the bronze armour one.

It was all totally weird and extremely frustrating that something which seemed so simple became impossible for hours. I have opened and shut the toolset to look at messed up armours inbetween changing files into different places with capital letters or not, back to front, upside down and every which way possible too many times to count. All I know is that it works perfectly in a different folder and I didn’t change the dds numbers at all, just renamed mdbs.

So perhaps there is more to how the game reads an override than there seems and not everything is visible. Strange thing is that something was being read as the armour always showed but was wrong and sometimes with bits of the outline of the original armours showing with/ without textures.

you’ve lost me somewhere along the way… why exactly do you rename textures? you rename the filename of the .mdb and the packets/meshes inside the .mdb. the new name has to be exactly like the name of the armor model you want to replace, and they have to be identical (filename and packet name).
textures are linked within the .mdb file, but you don’t change that unless you know what you’re doing - there’s also no need in your case. file name and texture name don’t have to be identical. the engine does not select textures by naming convention.
the textures worked in your second example because you didn’t rename them. they still had the same name which is linked in the .mdb file. that is you did not change the linked name to the new name you gave to rename them identical to the .mdb. again, this does not work without changing the texture link within the .mdb too, and there’s absolutely no need for this with what you’re trying to accomplish.

Semper… The naming of the textures ( the three dds files inside the mdb with n or t after them etc. ) made no difference. If I changed them to the name of the mdb or left them as they were originally.

Trust me I tried everything and every possible naming style and combination of everything I could think of. Capital letters or not, original dds names on the textures or same as the mdb file ( I also changed the texture file names of course if I did this ) add that with a variety of alpha transparencies being on or off and being triple checked for typos and what you’ve got is a lot of combinations reloads and frustration !

The only thing that made it work was putting it in a different folder from another mod. That’s all I know, so that alone was something to do with the issue and nothing to do with naming of files because it worked as soon as I put the mdb in the new folder.

It really doesn’t matter because it works now and I hope nobody goes through this nonsense again, so my advice still stands to stick it in another folder if it doesn’t work first time.

You may find this hard to believe because I did too and that was the worst part of the hours spent messing about with files.

By any chance, wouldn’t the path of the different folder be longer than the one you first tried? In that case, there was a conflict with two mdb having the same name (your newly made one and another one, the latter probably not compatible with the textures [UV mapping comes to mind] or the skeleton [not sure what you mean by “came out wrong” or “messed up”]).

I think that you probably have a conflict, but changing the location of your newly made mdb gave it a higher priority (see here or here for details).

To put it in a nutshell, as Semper explained:

  • the names of the packets in the mdb need to be exactly the same as the mdb itself (except for the _L01 and _L02 suffixes, that are meshes with fewer faces than the main one, as they are shown from farther away).
  • the textures must not be changed, unless the modifications take place on the same places (in other words: you can change the colors, add a scar or a tatoo, but cannot change the location of the head or legs etc… on the texture as they are recorded in the mdb).

Let’s take an example: let’s say you want to replace P_HHM_CH_BODY12.MDB with P_HHM_HD_BODY06.MDB.

  1. open P_HHM_HD_BODY06.MDB with MDBCloner or MDB Config,
  2. change the names of the packets (in MDBConfig) / MDB (in MDB Cloner)


    from P_HHM_HD_BODY06 to P_HHM_CH_BODY12 (with MDB Config, do this also for the _L01 and _L02 packets, keeping the _L01 and _L02 suffixes)
  3. do not change anything else, just save as p_hhm_ch_body12.mdb (NWN2 doesn’t make any difference whether there are capital letters or not in the files names).
  4. put the new p_hhm_ch_body12.mdb in your My Documents<NWN2 installation folder>\Override directory (or in your campaign folder if you don’t want to lose the original p_hhm_ch_body12.mdb armor appearance in the other modules - remember the order of priority).

I understand that’s what you already did, in which case the only reason for your modification not showing up as expected is due to a conflict (either with UV maps not matching the new textures or because of two or more mdb files with the same name as the one you just created).

2 Likes

4760… I really don’t know what happened and it probably was some sort of clash or priority thing but the folder change did it. I am not alone with this issue and it might have something to do with the way the mod was, I dont know.

Look at the comments in this link and someone else had an issue and unlike me probably knew what they were doing. https://neverwintervault.org/project/nwn2/model/new-beautifull-armors-hairstyles-and-weapons-override-version

This is not the mod I was using as mine is different and was from another site because I didn’t know these were here but it’s got a lot of the armour in and is from the same creator.

I wish I knew NWN doesn’t worry about capitals ! I tried swapping that about a lot ! Anyway thanks for the info and shots and I hope anybody having the same sort of issue finds this post because it’s now certainly full of information and not just me freaking out !

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:

  1. 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.

  1. 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.

  1. .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:

  1. 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.
  2. 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?).
  3. 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.

2 Likes