DarthParametric

More correctly, this is the OdysseyBase. Incorrect. Meshes can indeed be child objects of null/dummy/empty objects. Indeed, this is actually a requirement in some cases. Specifically, what is known as the "A node". This applies to level models where any animated mesh must be the child of a null/dummy that is named the same as the OdysseyBase with "a" appended to the end. Except in the case of walkmeshes, which use the walkmesh multi-material, not a usual texture reference. I'm not sure how Blender handles UV channels, but lightmapped level models absolutely require a second UV channel for the lightmap UVs. One thing you have missed is that each node requires a unique ID. This is important for character models because bone ID must match the equivalent ID in the supermodel hierarchy. The KMax/MDLEdit workflow gets around this by loading the target supermodel to map the nodes where needed, but KBlender compiles to a binary directly so requires they be set in the editor. I recall I was playing around with an automated mapping script at some point. I know I talked to seedhartha at some point about adding it. Not sure what became of that.

Something extremely useful for mod testing/debugging would be to make the ShipBuild() function functional. That would allow external script logging as well as on-screen script notifications using the vanilla include debug functions like Db_PostString. Although I'm not sure how much of the related logging code was just excised altogether.

Looks like he needs a few sutures.

The issue is that appearance overrides are bugged and require a txi on the first (01) texture variant. If there isn't one then the engine will ignore TXI data on subsequent variants.

And did you enable the bumpmapable flag on her meshes?

That's what the bumpyshinytexture semantic is for, it enables both simultaneously. But it comes with the downside that both share the same alpha mask, so you can't have one type showing in one section and the other type showing in a different section. You get both or neither. Although for the normal map you can at least make it flat in sections where you don't need any detail.

You don't need anything special for envmaps. Only normal maps require a mesh flag to be set. "Gloss" is just a cubemap being blended with the diffuse according to the alpha mask.

Not exactly, no. The original source was Jakarro, an NPC from one of the expansions that was a lot beefier than the vanilla Wookiee model they had: The bits for Hanharr were modelled mostly from scratch I think, from memory. The Zaalbar belts were taken from one of the scrawny Wookiees and sliced and diced to fit the new model: And of course there was some massaging required to get the model to fit the KOTOR Wookiee rig.

It was never released. It was just something I was playing around with. But here are the models and textures if you want to try generating some new textures. If you produce something you like you're welcome to release it yourself. Although it seems I never got around to remapping the Zaalbar belt meshes to fit into a more reasonably-sized texture. I can probably do that for you if you do decide to release it. Re-exporting the models with the vanilla names would also make life easier. There's also presumably the issue of female Wookiees needing a replacement in such a mod. TOR does have a scrawny Wookiee model that would work I guess. TOR_Wookiees.7z

There's always the TOR Wookiees. Their original textures are pretty cartoony.

Yes. For normal maps to work, each mesh that the normal map is applied to must have the bumpmappable flag enabled. You can do this relatively simply by loading the model into KBlender, selecting any appropriate meshes, and enabling the flag in the KOTOR properties section before re-exporting.

As the name implies, it's a distortion VFX for the force cage placeable.

TXI data is embedded in a TPC, as long as you tell TGA2TPC to include it.