DarthParametric

Ah, ok, that tracks more with my expectations after my aforementioned previous discussions on the matter with ndix UR. But if you have enabled some provision for debug messages then that is extremely useful. Traditionally the only option has been using SendMessageToPC to pipe stuff to the Feedback window, which is pretty limiting. Although speaking of which, if you can increase the scrollback buffer of that window, that might be another handy change. On a different note, something else that comes to mind is the debug camera option that they left in the Xbox version but apparently removed entirely for the PC version. If you don't already have access to the Xbox version I can give you the XBE to look at, if that's of use/interest. Maybe there are other goodies in there that are missing from the PC version.

Ok, so the print string stuff still appears to be functional then? What about external logs? Does it dump any of those? I recall asking ndix UR about it once when he was going through the Apple Store version and he suggested that they probably removed the code for it. There's already an existing exe hack for that - https://deadlystream.com/topic/11814-kotor-1-level-cap-mod-to-level-50/

The problem with the vanilla lightmaps is that they reduced them down to tiny sizes. In some cases a single room might comprise two or three lightmaps each only 64x64. So whatever quality they were in their raw state (probably not that high res to begin with circa a quarter century ago using 3DS Max 8/9 and Photoshop 6/7), once they crunched them down for the shipped version everything got turned into blobs. It's honestly impressive they look as good as they do, all things considered. But they didn't "paint" them. If you look in the vanilla models you'll like see a bunch of empty null/dummy objects with light names. Those were all the fill lights they used originally to bake the lighting. They presumably got converted to nulls by their exporter since they weren't of an appropriate game type. As to vertex painting, no. The engine doesn't support displaying any colour information that way. Not that it would help you for lightmaps anyway.

Lightmaps are arguably the hardest thing in KOTOR modding, both because of the fiddliness of setting them up and baking them in the first place, but also in trying to match the vanilla artistic lighting intent (assuming you are baking vanilla modules). It's a lot more straightforward in custom modules where you don't have pre-existing restrictions. To the first part, KBlender has made the baking process a hell of a lot better than it used to be in KMax, albeit you have to deal with all of Blender's alien logic for the setup. Since you mentioned UVs, I take it you're not doing this, but it's worth noting that you can't use vanilla lightmap UVs because the bakes will be terrible, even 20 years later at 50+ times the resolution. I gather Bioware baked the maps and then repacked the UVs afterwards for performance reasons on the Xbox, remapping the lightmaps to suit. My experiments with KBlender routinely found issues across UV seams, so my suggestion is to try and keep to contiguous islands as much as the geometry allows. In practice, this means condensing all meshes with shared diffuse textures as much as possible. I'm not sure how you do this in Blender, since I don't use it for modelling. Same with remapping the UVs - no idea how to do it in Blender. To give you an idea of the sort of thing I'm talking about, here's an example from some of my rebake experiments with the "hangar" of the Dantooine enclave. You can see most of the main floor geometry is a single contiguous island to minimise seam artefacts. At the bottom is a comparison of the vanilla maps vs the re-UV'd/rebaked maps.

The target would be his UTC file, since that's where his inventory is stored. As to how you'd do it, while you could just edit the UTC directly and add it to his inventory via Holocron Toolset or KGFF, a better approach might be to use scripting to do it, since that allows for more control. It would also mean it wouldn't be affected by the edge case of people loading a save where he had already been spawned before they installed the mod, since in that case a modified UTC wouldn't take affect (creatures, placeables, etc. are saved in the GIT file stored in the user's save as soon as they are spawned). Probably not a big deal in this instance, but it can be a significant consideration in other circumstances.

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.