DarthParametric

I assume you mean the normalhead value for your added row in appearance.2da is 110? Does your UTC have a unique resref/tag?

You'll need to create a new heads.2da row and a new appearance.2da row. Reference the row ID of the former in the latter. Point your NPC UTC/s at the new appearance. K1 or TSL? If TSL you can specify a texture override in heads.2da, which makes things easy. For K1 you will need to have a custom head model edited to point to your custom texture.

Yes, if you want them to be unique. The only other option would be to incorporate them into the room model. It may still be possible to call the animations via script in the same fashion as the vanilla game. You can do so in TSL at least, not sure about K1.

At this point only the protocol droids and astromechs are "confirmed". There are some technical issues with the models that need to be resolved, and some texture adjustments required, but otherwise they are more or less done and will probably/hopefully be released at some point this year. The only other thing close to a realistic prospect in the short term is the Imperial Autotrooper as a replacement for either the Assassin Droid or War Droid. The low poly model is complete and unwrapped, but I haven't done any high poly bakes or texture work as yet. Beyond that, I was thinking about maybe revising/updating the HK models and textures, but I'm not in any particular rush to do so. The hold-up at the moment is that I have some persistent and seemingly unresolvable system issues preventing any modelling work, so things have been on a forced hiatus since the end of last year. I probably need to do a clean install and start fresh, but that's always such a pain in the ass so I have been looking for any alternative to avoid that (with no success so far).

That was for K1. TSL already has those values so it doesn't require changing.

The ModelB and TexB columns. You should be able to use N_CommF for both if you want regular clothes. This is how TSL's player rows are set up, so you can use those as a guide.

The only way around that is to edit appearance.2da.

The TXI data is a mixed bag. Some are perfectly fine, some are complete garbage, some are the data surrounded by garbage. I've never seen KTool spit out an ABGR normal map. However, it quite often crashes when trying to display them. Maybe that's the difference?

If you point them to a player's appearance.2da entry. But in that case make sure you edit their inventory and equip whatever armour/clothes you want them wearing.

Change the "forpc" column value from 1 to 0 in portraits.2da for any player heads you want to remove as selectable. Presumably you'd want at least one male and one female though, and even then the game might get screwy (it may want at least one unique head per class and sex). You'd have to edit the appearance.2da row of a given NPC (or class thereof, like commoner) and change the "normalhead" value to whatever heads.2da row ID you want. If you want specific NPCs to have specific heads, you'll probably need to make new unique appearance.2da rows for them. Then you'd need to edit that NPC's UTC to point to the new appearance.

ABGR? You sure that's not a consequence of your fruity OS? I don't recall seeing that. You have any specific examples?

Use KOTORTool to extract all the TPCs from the texture pack ERF. Then, to quote myself:

Not that I can recall seeing firsthand, but I can't really claim to have exhaustive knowledge of level-related stuff, it has never been my thing (at least in regards to KOTOR modding).

If you are baking a custom layout, then you are unlikely to be doing so with any modifiers in the stack (especially if you are following Quanon's routine). In which case the eventual walkmesh would be just like any other mesh. The question is what happens when you dump a walkmesh modifier on it, which should be easy enough to test with any pre-existing lightmapped mesh. No need to bake one from scratch.

There's nothing inherently special about a walkmesh that makes it different for lightmapping compared to any other mesh, at least as far as Max is concerned. Give it a set of lightmap UVs on channel 2, bake the shadow maps as you would for any other mesh. Perhaps you could have KOTORMax export a dummy version of the mesh with the lightmap UV and texture data (perhaps even as a separate file, like you have for PWK/WOK), then merge it in MDLEdit? Assuming that solves anything. If you have a university email address, you can get an educational version of Max for free - https://www.autodesk.com/education/free-software/3ds-max

Chances are it won't be 100% compatible, but I've never used it so I couldn't say for certain. Basically if the NPC Overhaul changes any scripts/GITs/etc. to point to different UTCs than what TSLRCM uses, then those instances won't receive hologram fixes. The only way to find out would be to install both and see. Just make sure you install NPC Overhaul first, then the Hologram fixes afterwards.

That's weird. You'd think that shouldn't matter if you aren't standing in either but rather the room in between (which they are both supposed to be visible from).

Have you got a save for one or both? I'll test it on the GOG version, see if it happens there.

Having a look at the level and the VIS, it seems like it should be working properly. Both of the access corridors, 302NARaf and 302NARap, are listed as visible from 302NARr, which is the Serroco side shown in your pics. So it seems like that shouldb't be the problem.

Seems like it's probably a visibility issue, with with connected room not listed in the VIS file for the room the player is in. Although if that's the case then it should be in all versions of the game, I don't think Aspyr modified those.