DarthParametric

Looks like he needs a few sutures. 

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?

3 hours ago, vurt said:

glossy and bumpmap / normal map together doesnt work afaik

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. 

12 minutes ago, vurt said:

no need to edit the mesh

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.

31 minutes ago, vurt said:

So these are straight from TOR? 

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.

21 minutes ago, vurt said:

Do you have a link to the mod?

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

49 minutes ago, vurt said:

maybe a new model

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

2 hours ago, vurt said:

So for doing normals on heads i bet you must edit the models

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.

2 hours ago, vurt said:

No idea what the texture even is, it looks like smoke. 

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.

6 minutes ago, Salk said:

it would be good to have some sort of software that prints out what textures each game model uses

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.

28 minutes ago, vurt said:

you mean to be able to select it separately from the other player faces i take it. 

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

30 minutes ago, vurt said:

would any of this lead to issues?

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.

31 minutes ago, vurt said:

it is obviously also possible to change head during play

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

4 hours ago, vurt said:

I need to look up some mods doing player races, see what is needed. 

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.

52 minutes ago, vurt said:

So i am guessing those mods will end up pretty broken

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?

On 9/3/2025 at 8:54 AM, Dark Hope said:

I saw a tail sticking out

The hood could be edited to push it further back. I'll have a look at it when I get the chance.

On 9/3/2025 at 8:54 AM, Dark Hope said:

It looks like "blending punchthrough" by default causes this effect.

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

4 hours ago, vurt said:

it was 2 days of converting for nothing 😕

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.

8 minutes ago, vurt said:

Wasn't expecting converting to tpc to be so slow

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?

11 hours ago, Erdan5 said:

is it true that you can't control the "fadeout" effect in a cutscene in KOTOR and that it happens at random?

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.

11 hours ago, Erdan5 said:

in some videos,  he falls down a different angle and different position than usual.

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.