DarthParametric

Hrm, I seem to recall this coming up once before, now that I think about it. Perhaps on one of the Discord channels a year or two ago. It might have been something ebmar was experimenting with. There is a way to forcibly do it via custom head models with incorporated masks, but that's not a particularly desirable approach for more than one or two instances.

Struct ID 1 is the head slot. For a beginner, using KTool is probably the best way to get started until you learn the inner workings of GFF. If you are only making mods for your own personal use then you (mostly) don't need to worry about KTool's drawbacks. It's only when making mods for public release that I would caution against its use. Hopefully Holocron Toolset will eventually supplant it altogether, but its GFF editors are still far too flaky to trust just yet. Additionally, your target NPC may need to meet certain requirements to equip some headgear, just like weapons and armour. Also, the ultimate limitation for headgear is whether or not the head model being used has the appropriate hooks. If it doesn't then everything else is moot. It would be advisable to do your initial testing with an appearance that uses a PC head to rule this out.

Here's an alternative for the severed arm one with an added glass floater mesh for the cracked screen. The glass mesh has an alpha of 0.75, which may need to be adjusted down to something more like 0.5 or lower. I've provided a placeholder texture from one of those AI generated ones I posted previously. Alt_Datapad_Severed_Arm_Cracked_Glass.7z

It's really not a big deal. It's like a 5 minute job. Duplicate the screen mesh, raise it up a couple of mm, assign it a unique texture, export the ASCII, compile to binary model.

Yeah to be honest unless you are planning on adding a cutscene where the player picks up the datapad so that you get a good look at it close up, it's probably just too much noise for such a small object. Edit: If you really want to add the broken screen, one option would be to add an additional floating mesh above the screen that has its own texture that you could use for the broken glass effect. Breaking it out separately from the animated screen texture might help it via more pixel density.

This is the safest approach, since any input can be ignored as desired. Having worked in a number of large team projects, both in game modding and elsewhere, the problem with other people is that they all have ideas. Worse still, they labour under the impression that their ideas are actually good.

Eh, you get what you pay for. I did say it was pretty half-assed after all. Having a look at the screen WIP thread, I was thinking that the hinge (?) cylinder on the datapad could probably stand to get a few more polys to round it off. Edit: So I started out rounding off that back cylinder, which lead me to just remaking the whole thing: That necessitated new UVs, so the vanilla texture layout won't work. But on the upside, there's less to fake now with some real geometry. I also split the screen out to its own texture, so you can take advantage of the extra real estate. The severed arm version has its own separate textures. I also fiddled with the stump end of the arm a bit, but there aren't many polys to work with. Placeable_Datapads_New_Datapad_Model.7z

There are a bunch of broken glass/screen textures available. I recall in the past also having a PS brush preset for it. You should be able to find something suitable under one of the Creative Common licenses (for example). And of course these days there's always the "AI" route to generate your own from scratch (for example here or here). Here are handful of AI ones I got with some quick messing around: AI_Glass_Images.zip People more familiar with that sort of thing could no doubt produce some better quality images, but I don't think you need anything crazy for a tiny datapad screen, especially since it's only going to be a semi-transparent overlay. As to the model viewer, I have never used it, but assuming it doesn't have a readme explaining it I would probably take 3DS Max controls as a good starting point to test.

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?