DarthParametric

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.

Normal maps must be TPC. They don't work as TGAs. How to create the TPC with correct TXI data is covered in this post. Handedness/direction of the map is covered in this post. And yes, there's generally minimal gain to be had from using them since Odyssey's implementation is so piss-poor.

A 1060 should be fine. Are you on Windows 10 or 11? If so, you can try this. Go here - https://github.com/mmozeiko/build-mesa/releases/latest - and download either mesa-d3d12-x64-xxxx or mesa-d3d12-x86-xxxx, depending on whether you have x64 Windows or not. Open the archive and extract opengl32.dll and put it in the game's folder next to swkotor.exe. This is a wrapper that will run the game in DirectX 12 instead of OpenGL. Might help with certain issues. Alternatively, there's also mesa-zink-x64-xxx/-x86-xxx that is a wrapper for Vulkan instead. They aren't compatible with GLIntercept or anything else that also hijacks the same DLL.

Attach that Tatooine save so I can test it on my end. What graphics card do you have?

The hood could be edited to push it further back. I'll have a look at it when I get the chance. Really? A couple of vanilla player heads use the same semantic. I did a quick test starting a new game with it and it worked fine. Without it, there were blending errors when the eyelashes overlapped the light panel on the wall in the background when talking to Trask. Try this - KFHC05.txi

TGA2TPC is finnicky. The last release version has some bugs with non-square/non-power of 2 textures breaking. Especially animated textures.

Presumably alpha channel masks for envmaps, like Sith troopers or Mandos, for example. Or the Hawk, both exterior and interior, amongst many others.

You're using ndix UR's TGA2TPC? I recall it had a memory leak at one point, not sure if that got fixed. Might want to try it in smaller batches and then close and reopen it. Alternatively, it's possible pyKotor might let you batch convert, not sure.

Isn't his "state of the art security system" a glorified electric fence?

No, that is literally the opposite. Fadeout on object destruction is the default. You have to manually specify for fade to be disabled. Whether your video card can render it properly is perhaps another issue entirely, but unrelated to what the game is actually doing. Unless you use a stunt animation, the rotation of the die/dead animations are going to vary based on the creature's starting rotation. I would assume he is jumped to a waypoint for the final death shot, but that can still be a little inconsistent in terms of facing due to the way conversations work. So yes, it's probably going to vary a little, but it shouldn't do so in a significant manner. Especially since they are probably using static cameras which have a fixed position, so he needs to stay in the same spot to remain framed. That said, it's possible that TSLRCM changed things with the scene composition that might be a factor. I'm not sure.

It's more a case of ATI/AMD driver support for OpenGL being (still) trash whereas nVidia's support for it is competent. The script in question chokes DeNCS so I only have bytecode, but it's worth noting that both the vanilla and TSLRCM versions are set to use fade out in both of the DestroyObject calls the script makes. So whatever TSLRCM changed, it wasn't that apparently.