DarthParametric

Just realised I screwed up and accidentally left the vanilla arm mesh in the replacement PLC_SevrdArm model. Deleted that and recompiled the two versions of that. The stump bit on the new arm is pretty half-assed. Maybe I'll look at redoing that. Won't impact the datapad itself though, since that's now broken out to its own texture. Something else you could do, since the screens are now separate meshes in both for self-illum, is to give them their own unique texture. That way you would be maximising pixel density, since the animated texture would only be the screen itself, not any of the housing/case (the screen is only 1/4-1/3 of the vanilla texture). Let me know if you want to do that. Also forgot to mention these were compiled for K1. I'm not sure if they get used in TSL. K1_Datapad_Placeable_Replacement_Models_v2.zip K1_Datapad_Placeable_plc_sevrdarm_Alternate_Texture_v2.zip

PLC_SevrdArm is really terribly mapped. Ideally it should be remapped to map the pad to the same texture as PLC_DataPad and the arm to one of the commoner clothes models. In fact I'd just rip the arm off one of those models and replace the original, would be quicker. The same for the pad, you could just swap it out for the standalone pad. The other thing is that PLC_DataPad doesn't have any self-illum for the screen, while PLC_SevrdArm's screen does. All relatively straightforward fixes if you need a hand with them. Datapad_Placeables_UVs.zip Edit: Here are the suggested replacement models. The PLC_DataPad model splits the screen out to a separate mesh with self-illum. The PLC_SevrdArm model is completely remade. Now it uses the PLC_DataPad model and texture (and UV mapping), although there's also an alternate version using a different texture variant (plc_datapad02) if you want to make a different animation for it. Edit 2: Removed the original attachments. See later post.

Not sure he looks ancient enough though.

Pretty much exactly what it says: mods that dump a pre-edited copy of, for example, appearance.2da into the Override folder instead of using TSLPatcher (lots of old player head mods), mods that require you to replace dialog.tlk (like PC Response Moderation), mods that put pre-edited MOD files into the Modules folder (like NPC Overhaul). If you want to use a mod and the author doesn't explicitly state that it is compatible with K1CP then yes, you should ask them.

You have vanilla Jedi robe textures on (presumably) JC's TSL ported robe models.

All of the xxx_g meshes are bones. You don't want to be messing with those (or setting them to be rendered).

It requires its render check box being ticked and a unique node number in its KOTOR properties (Object -> KotOR Model Node).

The way the engine works, the "base" (i.e. first - xxxx01) texture requires the TXI data. That data is then applied to all other variants of that texture.

For those having errors when loading placeable PWKs (possibly also door DWKs?), it appears the problem is line 417 in \Scripts\KOTORmax\kotormax_scripts\odyssey_fn_import.ms: kx_enableMapChannel newObj 0 true which gives the error about wanting two arguments but getting three when processing the walkmesh. Changing it to: kx_enableMapChannel newObj 0 fixes the issue. Pre-edited copy attached for those that don't want to edit it themselves. odyssey_fn_import.ms

If you use the visual GUI editor you should be able to just drag the elements into place. You could use a screenshot to create a texture for it to load into the background so you can get the positioning correct.

No. As I mentioned above, almost all the models are straight from ndix UR's fix mod and untouched by K1CP. Off the top of my head I think the only change we made is to the central room to adjust the walkmesh, but that was presumably back in 1.8.0, since that was when JC and I got directly involved and the project expanded in scope. But ndix UR's models predate that, going back to the very first 1.0 release.

There's nothing in a save that would cause this, and indeed I didn't have the issue on my end loading one of your saves. I can kind of understand odd graphical issues on an AMD GPU, as their drivers have been garbage since the ATI days, especially for OpenGL titles. I'm surprised that it is also occurring on an entirely different system with an nVidia GPU though, albeit one that is pretty old. But I have a dual boot XP/Win 7 box for old games that has a 560 in it which is even older, and it has never displayed that issue in either K1 or TSL (and beta testing playthroughs of the last two K1CP releases were primarily done on that box). Since I can't reproduce the issue, I can't really do much to try and test for fixes. But I'll have a look at the EH models and see if I can spot anything noticeably different from the vanilla models. My guess would be something related to the lights.

I'm curious about what the root cause of your problem might be. What OS are you running on? GPU make/model?

Can't say I have ever experienced it, nor do I recall it ever being reported by anyone else. I'm pretty sure we'd have heard plenty of screeching about it by now if it was something we did that affected everyone. You can try removing all the m12aa_01xx MDL/MDX/WOKs from your Override (most of which are originally from ndix UR's Ebon Hawk Fixes mod). I don't think there's anything else relevant to the Hawk that K1CP changes.

No. I don't recall the permanent slow bug occurring in TSL. I've never even encountered it personally in K1, only seen reports of it.

Yeah this is almost certainly a mod clash. Some random 3rd party mod that dumped some crap in the Override and broke something.

That robe model problem has existed for more or less the entirety of TSLRCM (and was fixed in K2CP). It's not the cause of OP's Dantooine bug. A black screen issue is either a script or cutscene bugging out, presumably after having initially fired HoldWorldFadeInForDialog() and never gotten to firing the fade-in due to the sequence break.

Primarily, yes, the ability to store the TXI data in the image file itself. It should be noted that the latest version of TGA2TPC has adjustable compression levels, so that may be worth experimenting with if you haven't already. It does seem like the default level of compression it uses is much more aggressive than Bioware's original implementation.

It's from Cortisol, creator of Holocron Toolset. It's still a work in progress, but so far it can handle installing 99% of most TSLPatcher setups. Hopefully its capabilities will be expanded in the future as well (like adding new TLK patching functionality, for example). The fact that it is open source and in Python, a popular language, means there is potential for cobbling together a custom installer as I suggested above. I don't think anyone is using it as their primary installer right now (although technically HoloPatcher is designed to be standalone and work with existing INIs). But in the future I can see abandoning TSLPatcher and migrating K1CP to it once new features are added. Plus it offers native multi-platform support.