DarthParametric

Did you add textures as well? It could be they need to be downsampled for Xbox.

Are the normalhead values you are referencing in appearance.2da new rows in heads.2da, or existing ones? If you are editing or replacing heads.2da, I am guessing the former. What happens if you add a new row to appearance.2da and point it to a pre-existing head?

Hrm, I wonder if this is the source of some visible geometry gaps I was getting from snapped verts. I might have to run some MDLEdit vs MDLOps comparisons. It seems like 5+ sig figure vert co-ords are present in KOTORMax-generated ASCIIs as well. Although to be fair to bead-v, I gather this is just straight from Max. I wonder how accurate the snap tool is? Maybe I should try using a vert co-ord copy/paste script. I doubt that will make any difference, but if you want to try it then use Affect Pivot Only in the Hierarchy tab. For matching the pivot of another object, my preferred approach is to make the target mesh a temporary child of the mesh with the desired pivot, set the reference co-ord system of the Move tool to Parent, hit Affect Pivot Only, zero out the XYZ of the position, then select Reset XForm in the Utilities tab and hit the Reset Selected button. In the Modify tab, drag the XForm modifier underneath the Skin and OdysseyTrimesh modifiers so it is just above the Editable Mesh modifier. Then right click on it and select Collapse To. That will bake your transforms without destroying your skin.

I believe you'd need to set the Minimum 1 HP flag in the NPC's UTC, then in its OnUserDefined script when its health hits some specific value have it end combat and change the NPC's faction to neutral and probably use ActionStartConversation to launch a dialogue if you want it to happen in a cutscene (you could just have it walk/run to a waypoint and then be destroyed, but that would be kind of awkward if the player still has active control). You may want to check out existing examples of that sort of thing, like say the Malak fight on the Leviathan.

I think bead-v was thinking of using an Edit Normals modifier in Max and taking the normal data from that, which presumably would drop the use of smoothing groups (outside of legacy support I guess). I'm not sure what the Blender equivalent would be, but I guess it would take some work to keep both MDLEdit and MDLOps cross-compatible with whatever additional data from either Max or Blender that might be added to an ASCII.

There is supposed to be provision to smooth across meshes when using shared smoothing group IDs, but I have never seen it work, and I had @bead-v confirm that is not working as intended. I guess it is possible there may be some edges cases where it does work, but I have never encountered them personally.

Yes, I don't believe either MDLEdit or MDLOps are correctly smoothing across meshes. I have previously raised the issue with @bead-v, so fixing it is on the to-do list. It probably also requires changes to KOTORMax. The specific issue is down to non-unified vertex normals at the seams. The compiler is generating two separate normals for every pair of vertices, instead of a single averaged normal, as Bioware's compiler must have done.

Your basis for this assertion? I'm pretty sure Bioware had a handle on what they were doing. I'd put this in the "unnecessary restored content" bracket. If the community patch is supposed to be about bug fixes, this doesn't belong, even as a separate download. It should be a separate mod.

TOR's files are all stored in archives with hashed filenames. You need a program to extract them and a hashlist to generate the proper filenames. Unfortunately publicly available hashlists tend to be somewhat out of date, so more recent content is probably not accessible. Once extracted, the files are all arranged in various sub-folders. Some things can be found by a simple filename search, but other stuff might require searching through XML files to discover the actual filename of the thing you are looking for (body parts for clothes/armour being a good example). Format-wise: Models are in a customised GR2 (Granny) format. For dynamic (i.e. skinned) meshes, skeletons are stored in a separate model. You'll need a Max or Blender script to import. As mentioned above, terrain meshes and level layouts are stored in some sort of (presumably custom) DAT format Textures are standard DDS Animations have been figured out privately, but there is no publicly accessible import script available Audio is stored in Wwise formats. Dialogue is in ACB and BNK archives, music as straight WEMs. These probably need to be manually listened to in order to find specific lines. UIs use Scaleform (a game-centric derivative of Flash) A current extraction of correctly named files in something in the order of ~50GB, ~600K files, ~14K folders. I'm not sure how much is missing, probably multiple gigs at least.

Regarding TOR areas, as far as I know only static meshes like buildings and so forth are extractable as usable meshes. The terrain meshes and layouts are stored in a file format that there is no publicly available importer for (that I know of). So you could partially recreate environments, particularly indoor ones, but it would all have to be assembled by hand from the component pieces. For outdoor areas that rely heavily on a base terrain mesh, say something like Tatooine or Hoth, you'd be out of luck for big chunks of it unless you modelled it from scratch. Or unless you could find someone to reverse-engineer the file format and code some sort of import/conversion script/program.

One thing I should also mention is that your normal map needs to be in OpenGL or +Y format (also known as "right handed"). Most apps will typically export normal maps in DirectX format (-Y, left handed). It is easy to switch between the two simply by inverting the G channel of your normal map. You can tell which one you have by looking for raised details. In an OpenGL normal map, these will appear to rise out of the image. In a DirectX normal map, these will appear to sink into the image. Like so: Images taken from - https://www.turbosquid.com/3d-modeling/stemcell/materials-texturing-stemcell/stemcell-texturing-guide/

No, they must be different names. The diffuse will be pfbselven01.tga and also have a TXI file named pfbselven01.txi. That will contain something like: bumpmaptexture pfbselvenb Then the normal map will be named pfbselvenb.tpc (or whatever else you decide to call it - just make sure it matches what is in the diffuse's TXI). It will not have a loose TXI, but it will contain the TXI data that you specified during conversion. This will be something like: isbumpmap 1 isdiffusebumpmap 1 bumpmapscaling 3 You can change the bumpmapscaling parameter to 1, 2, or 3 depending on how you find the look of the intensity. Typically the engine is pretty piss-weak with normal maps, so they need an intensity boost to see any significant effect.

Yes, DXT1/5 is DDS compression and will result in artefacts. I would not convert the diffuse to TPC - leave it as a TGA. The normal map must be converted to TPC or the game will freeze/crash when loading.

Use TGA2TPC to convert your normal map: Make sure it has a white alpha channel and save it as DXT5. Create a TXI or select the text option to just manually enter the info. You don't need it afterwards - the info is stored in the TPC.