DarthParametric

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?

Is that relevant? It's on Github. That shouldn't be the case from what I recall, since the door should be locked and signal the trooper to initiate a conversation if you try to open it. If it is broken then nobody bothered to tell me about it. But there's nothing stopping someone from using that mod as a basis to make a "proper" version if it's required. It would be useful if people would create an issue for this type of thing on the K1CP repo. Soon™. I did a basic fix of that ages ago that just duplicated the vanilla GUI image. Functional, but not particularly pretty.

What's the problem?

No, nothing further at this time. The lip sync is still off and there's no solution for the black mist overlay VFX in a realtime cutscene. Although the latter could be solved by keeping it a pre-rendered movie, just creating a new higher res one.

Yeah, the revelation scene is bad for big hair. K1CP does adjust the hood to fit vanilla hair though. You should try downloading the MDL and MDX and testing them out. Anyway @WhiteSaber, the mystery has been solved. It's a one-off, so no soup for you.

Huh. Well of all possibilities, that wasn't on my bingo card.

Doesn't look like it. As far as I can recall, the only human heads I ported were for Kira (doubles as the TOR Jedi Exile with different hair) and Jaesa, and that's not either of them. Doesn't appear to be any of the vanilla K1 or TSL heads though. The hair definitely has that chunky TOR look to it, but having a quick browse through the TOR Community character creator tool I couldn't see it. However, if you look at what I assume is Canderous on the left, you can see he has rounded ears. That's a dead giveaway that it's not a vanilla head, since those all have blocky rectangular ears. My guess is that this is from some sort of "high poly" head mod. Doesn't appear to be a mod that's hosted either here or Nexus that I can see from a quick search though. @Dark Hope: Where does that female head model come from?