DarthParametric

The issue is that appearance overrides are bugged and require a txi on the first (01) texture variant. If there isn't one then the engine will ignore TXI data on subsequent variants.

And did you enable the bumpmapable flag on her meshes?

That's what the bumpyshinytexture semantic is for, it enables both simultaneously. But it comes with the downside that both share the same alpha mask, so you can't have one type showing in one section and the other type showing in a different section. You get both or neither. Although for the normal map you can at least make it flat in sections where you don't need any detail.

You don't need anything special for envmaps. Only normal maps require a mesh flag to be set. "Gloss" is just a cubemap being blended with the diffuse according to the alpha mask.

Not exactly, no. The original source was Jakarro, an NPC from one of the expansions that was a lot beefier than the vanilla Wookiee model they had: The bits for Hanharr were modelled mostly from scratch I think, from memory. The Zaalbar belts were taken from one of the scrawny Wookiees and sliced and diced to fit the new model: And of course there was some massaging required to get the model to fit the KOTOR Wookiee rig.

It was never released. It was just something I was playing around with. But here are the models and textures if you want to try generating some new textures. If you produce something you like you're welcome to release it yourself. Although it seems I never got around to remapping the Zaalbar belt meshes to fit into a more reasonably-sized texture. I can probably do that for you if you do decide to release it. Re-exporting the models with the vanilla names would also make life easier. There's also presumably the issue of female Wookiees needing a replacement in such a mod. TOR does have a scrawny Wookiee model that would work I guess. TOR_Wookiees.7z

There's always the TOR Wookiees. Their original textures are pretty cartoony.

Yes. For normal maps to work, each mesh that the normal map is applied to must have the bumpmappable flag enabled. You can do this relatively simply by loading the model into KBlender, selecting any appropriate meshes, and enabling the flag in the KOTOR properties section before re-exporting.

As the name implies, it's a distortion VFX for the force cage placeable.

TXI data is embedded in a TPC, as long as you tell TGA2TPC to include it.

It wouldn't be particularly hard. Wizard and I created a Powershell script to dump all the lightmap assignments in K1 to identify all the cases of missing lightmaps. You could do the same thing for diffuse textures.

Someone picked up the project and created an active fork - https://github.com/modawan/reone You can keep tabs on their progress via the OpenKotor Discord, along with other engine reimplementation projects. As to seeing it in action, well you can always pull a copy of the repo, compile it. and test it out directly. Or maybe someone on the Discord can provide precompiled binaries.

Yes. Adding it as an additional head rather than simply overriding an existing head. It requires new rows in appearance.2da, heads.2da, and portraits.2da, plus a uniquely named head model (and textures, which is obviously the primary goal in this case). Possibly compatibility issues, especially for more popular heads (like Mullet Man). While it takes some initial setup the first, a custom head is pretty easy to knock out once you've done it once or twice. You can do this by editing the save with KSE and changing to whatever appearance you want (including the other sex or non-player races).

There's nothing particularly complex, unless you want custom models for alien races. You will need to at least have a custom named model for each added head. Both the filename and the internal OdysseyBase name. This can be done via a hex editor if you don't want to deal with loading up the model, otherwise Blender with the KotorBlender I/O script will do what you need. The base (LS) diffuse texture needs to be specified in the head model directly in K1 (TSL added the option to apply it as an override in heads.2da). Everything else - the DS transitions and portraits, adding it as an additional option in the character creator - is just 2DA and ini setup. Technically you don't actually need to edit any 2DAs. Once you know what you're doing you can just generate the required data in the ini directly. There should be some posts around detailing how to set one up. I thought I posted a template TSLPatcher setup for it at some point. I'll go digging tomorrow.

No. That specific warning is just saying that a MOD (overrides a module's RIM pair) already exists, so it doesn't need to put a copy there first. Changes will just be injected into the existing archive. It's probably the most common misconception about how TSLPatcher works, and unfortunately its presence has a knock-on effect because people say to ignore it, so users then assume they should ignore all warnings, which is not the case. Suppressing this message was high on my list of feature requests for HoloPatcher, TSLPatcher's successor.