DarthParametric

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.

It's a variable in the function: void DestroyObject(object oDestroy, float fDelay=0.0f, int bNoFade = FALSE, float fDelayUntilFade = 0.0f); It is set to fade by default, so you have to manually specify no fade. There have been multiple iterations/revisions of that sequence in TSLRCM over the years. It's also possible some other mod edited it. I couldn't say, since I don't have any interest in TSL so don't pay attention to stuff going on with it. Check your Override folder for a script named a_end.ncs and find the Modules folder and attach 852nih.mod here so I can look at it.

Probably a script change that didn't specify fadeout on object destruction.

Create a TXI for the face texture and the DS transitions containing the following: blending punchthrough I'm not sure that will fix it, but it's worth a shot.

Does that only happen in the revelation cutscene? Or any cutscene/conversation?

It would have no effect on an OnEnter or other module entry behaviour. The reason it exists is possibly a holdover from NWN, not sure. But in principle there's no real danger in initiating a module transition with the party scattered across the map. Although you'd probably want a safety CancelCombat on the party first just in case one of them is off somewhere fighting mooks by themselves. Well that's an entirely different kettle of fish. That's a manually initiated scripted transition, not a specialised trigger that has a hardcoded distance check. If someone wants to add elevator buttons in modules where that's appropriate then you could use that approach, but it's not going to work for cases where you are supposedly just walking through a door or along a pathway, like say most of Manaan or the Dantooine plains. I suppose you could replace all the existing transition zones with regular triggers with a simple scripted transition, but you'd be editing multiple structs in every GIT in the game. Talk to JC, maybe he can come up with a way to automate that sort of hackery with a custom program. Just a note though that going that route may have wonky behaviour. I know when I used such a trick in K1CP to handle preventing transition to the Hawk during fights with Xor that the usual transition fadeout broke and needed a dummy DLG with a scripted fadeout to mask it. If I find it interesting enough. Usually it goes hand-in-hand with lightmap adjustments. The door should have a key added by K1CP I believe (vanilla behaviour is locked with a DC100 check). The issue is that the vanilla OnFailToOpen script only checks for at least one instance of the Sith armour. It just needs an update to check for two/droids like the edited guard script.

Define "behaves incorrectly". Edit: I can't really make out anything in that screenshot. Is it alpha blending that's the issue?