DarthParametric

The weighting is definitely different for that torso vert in P_MandaloreBB, but I'm still not seeing how that could cause a whole poly to disappear. I'd expect a gap around the edges, but not a hole. It also looks to me like the missing poly in the pictures above is different to the one with the mismatched skin weights (although that could just be due to the pose deformation).

Depends on the specific model. Something like a mask isn't typically too much work. Mostly repositioning and scaling the mesh to suit. Although in order to make effective use of KOTOR's self-illumination for the emissive parts of the texture, extra geometry typically needs to be added. This might be editing the original mesh and then repairing the UVs, or creating entirely new meshes. This is because self-illum is set per-mesh, so unless the majority of the texture is black then the entire thing will glow. For heads, as well as repositioning/scaling there needs to be a lot of mesh work to deal with KOTOR's limitations. That means splitting out the eyes, mouthbox/tongue, and teeth as separate meshes. Then the whole thing needs to be skinned to KOTOR's rig. Bodies are probably the biggest pain, because they are in more of a modern-style A pose. So as well as just scaling, the arms need extensive repositioning to match the KOTOR rig. Once that is done they then need to be skinned to the KOTOR rig. In addition to that, a more general issue with the import scripts is that its implementation of generating smoothing groups results in a mess that needs to be cleaned up. I think this is probably due to the way the mesh is split, so the first step is welding and then re-generating smoothing groups, manually assigning them where necessary.

Cool, glad it worked for you. Although I am still scratching my head over the arm issue with the original P_MandaloreBD. Perhaps @bead-v and @ndix UR could shed some more light on it by examining the binary model.

Playing around with some of the Jedi Knight visors. I think they will be good replacements for some of the vanilla masks: I haven't adjusted the textures yet, so they are still their default (mostly) brown. I also need to add some glow meshes for the first one, like you can see in the second and third ones. I think I'll also use an envmap for the lenses, give them a bit of reflection. Perhaps the first two could also have their lenses changed from black to something more bluish like the other two.

It looks fine in Max. There are no missing/flipped/overlapping polys in that location that I can see: Edit: OK, I have replaced the torso and arms with the P_MandaloreBB versions. Redownload from the link above.

The back two are holes where the hoses from the helmet would connect, so that's expected. They would need to be manually fixed. The hole in the arm is odd though. If the back needs to be fixed anyway, I'd probably just switch to the full body model as a basis and lop off the head. Edit: Looking at the vanilla P_MandaloreBD, I don't see any missing or flipped polys in the arm (there were some duplicate polys on the back though). Try this version with plugged holes in the back https://www.darthparametric.com/files/kotor/tsl/[TSL]_P_MandaloreBD_Hole_Plugged.7z

No, there is no specific KOTORMax thread (aside from the release and support threads). It was awaiting the creation of the promised Tools subforum. Edit: This thread is still pinned by the way - https://deadlystream.com/topic/4905-mod-of-the-year-voting-2016-kotor/

There are a few other stickies you could put a broom through while you are at it. The general modding sub-forum still has stickies for the 2016 mod of the year voting, and for NWMax which is now well and truly deprecated with the advent of KOTORMax.

It's cut content. It's was intended to be used with the bearded Canderous head. It was reinstated by TSLRCM for one of the holograms T3 can show you.

Ah yes, I forgot about that. Although testing it out, it crashes for me on Win10.

You need to decompile the model, then recompile the ASCII against the K1 S_Female02 binary supermodel. It's no different to compiling any other model. It uses the same rig as K1, so there's nothing special required in this case. You'd also need to add/change appearance.2da rows as appropriate. As @todevuch alluded to, TSL includes a body-only model, P_MandaloreBD.

It's an especially good practice to get into before modding TSL. For example, n_twilekf001.utc is used 6 times there. As I said above, K1 is generally pretty good with unique resrefs. I'd say around 95% of its resrefs are unique. But TSL, ugh. So many re-used/duplicate resrefs.... Edit: I should clarify that I am talking specifically about character resrefs here. K1 is much more generic when it comes to resrefs for things like placeables.

Hah, so doing a search in KTool, I can see one other instance of n_twilekf001.utc. The way the search tool works though doesn't specify the parent module. So I looked through every damn module in the game and where do I find it? STA_M45AD - the final level of the Star Forge. In other words, it's the UTC used for the Easter egg cheat "dancedancemalak". Given that, you are probably ok to keep it as-is, but this should be a lesson for future modding efforts: don't half-ass it, do it right the first time.

That's irrelevant if the resref (i.e., filename) is the same. K1 is generally fairly good about unique resrefs, but with such a generic name chances are high that there will be a clash. I suspect you'll almost certainly need to do a proper module injection.

It would appear to be an odd sort of greyscale bumpmap, almost pure white, so I'm not sure how significant it would be. Curiously neither TPC contains any TXI data, so I'm not even sure it is being used. Although the fact that the bumpmap has an alpha mask supports @ndix UR's suggestion regarding normal maps and alpha transparency.

You'll be wasting your time with normal or bump maps for leaves/branches. Aside from the fact that you'd not notice the difference, it's not compatible with alpha transparency. But to answer your question, no, you don't need Max/GMax. The flag can be set in the ASCII, as JC said, or in MDLEdit you can just go to Edit -> Textures and tick the box next to the one you want to use a bump/normal map. Note that if using a normal map it must be converted to a TPC. A TGA will cause the game to throw an error on loading.

I'd appreciate it if you could determine the specific source of the models. I'll probably need to add a custom Revan hologram model to prevent anyone else having the same issue, but I'm not sure why it is even crashing in the first place. You'll also presumably want to add the model back to your Override so whatever mod that added it in the first place isn't affected.

The only thing of relevance is N_DarthRevan.mdl/mdx. If you have that model in your Override, try deleting it and seeing if the scene still crashes. Beyond that, I don't have any idea what could be the root cause.

Well candholo.utc is pointing at appearance ID 760, which matches the custom holo Canderous appearance. Do you have DP_Canderous.mdl/mdx in your Override? Edit: Do you have any Revan mods? N_DarthRevan.mdl/mdx is also used in that scene.

Yes. An "island" in UV mapping terms is a single group of contiguous UV polygons.

Is this on Steam? Using the Workshop? I'd guess it's a crash caused by the UTC edited by the hologram mod pointing to an appearance.2da row it can't find, or the appearance.2da row not pointing to a model it can find. The most expedient solution would be to zip up your appearance.2da from the Override folder and 003ebo.mod from the Modules folder and attach them here.

The question being, why replace anything at all? Just add new 2DA entries that make use of the existing assets.

Well I can't make your life too easy. Especially when you serve up such easy pickings.