DarthParametric

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.

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.

It wouldn't be particularly hard. Wizard and I created a Powershell script to dump all the lightmap assignments in K1 to identify all the cases of missing lightmaps. You could do the same thing for diffuse textures.

Someone picked up the project and created an active fork - https://github.com/modawan/reone You can keep tabs on their progress via the OpenKotor Discord, along with other engine reimplementation projects. As to seeing it in action, well you can always pull a copy of the repo, compile it. and test it out directly. Or maybe someone on the Discord can provide precompiled binaries.

Yes. Adding it as an additional head rather than simply overriding an existing head. It requires new rows in appearance.2da, heads.2da, and portraits.2da, plus a uniquely named head model (and textures, which is obviously the primary goal in this case). Possibly compatibility issues, especially for more popular heads (like Mullet Man). While it takes some initial setup the first, a custom head is pretty easy to knock out once you've done it once or twice. You can do this by editing the save with KSE and changing to whatever appearance you want (including the other sex or non-player races).

There's nothing particularly complex, unless you want custom models for alien races. You will need to at least have a custom named model for each added head. Both the filename and the internal OdysseyBase name. This can be done via a hex editor if you don't want to deal with loading up the model, otherwise Blender with the KotorBlender I/O script will do what you need. The base (LS) diffuse texture needs to be specified in the head model directly in K1 (TSL added the option to apply it as an override in heads.2da). Everything else - the DS transitions and portraits, adding it as an additional option in the character creator - is just 2DA and ini setup. Technically you don't actually need to edit any 2DAs. Once you know what you're doing you can just generate the required data in the ini directly. There should be some posts around detailing how to set one up. I thought I posted a template TSLPatcher setup for it at some point. I'll go digging tomorrow.

No. That specific warning is just saying that a MOD (overrides a module's RIM pair) already exists, so it doesn't need to put a copy there first. Changes will just be injected into the existing archive. It's probably the most common misconception about how TSLPatcher works, and unfortunately its presence has a knock-on effect because people say to ignore it, so users then assume they should ignore all warnings, which is not the case. Suppressing this message was high on my list of feature requests for HoloPatcher, TSLPatcher's successor.

Normal maps must be TPC. They don't work as TGAs. How to create the TPC with correct TXI data is covered in this post. Handedness/direction of the map is covered in this post. And yes, there's generally minimal gain to be had from using them since Odyssey's implementation is so piss-poor.

A 1060 should be fine. Are you on Windows 10 or 11? If so, you can try this. Go here - https://github.com/mmozeiko/build-mesa/releases/latest - and download either mesa-d3d12-x64-xxxx or mesa-d3d12-x86-xxxx, depending on whether you have x64 Windows or not. Open the archive and extract opengl32.dll and put it in the game's folder next to swkotor.exe. This is a wrapper that will run the game in DirectX 12 instead of OpenGL. Might help with certain issues. Alternatively, there's also mesa-zink-x64-xxx/-x86-xxx that is a wrapper for Vulkan instead. They aren't compatible with GLIntercept or anything else that also hijacks the same DLL.