DarthParametric

Didn't @ebmar do something along those lines for use with some of those upscale mods? It's exceedingly easy to do yourself though via TPCView. This should be the majority of them, aside from lightmaps and a few other minor bits and pieces. K1.7z TSL.7z

Your registry key is incorrect then. KTool works fine with non-CD versions as long as it gets pointed to them. There's specific info about the keys in this post. But in any event, KTool is mostly outmoded now anyway. Try using Holocron Toolset instead.

Sounds like the same bug Aspyr introduced into their update/port of TSL. Although I don't recall hearing of it cropping up in K1 before. Mac Store version? I'd suggest the only real solution is probably ditching the Mac version altogether, grabbing the PC version and running it under Wine or equivalent. Keep your eyes peeled during a sale and you can pick them up cheap. You just missed the May 4th sale, but both games go on sale all the time. You'd likely want the GOG version rather than Steam.

Which should be noted have nothing to do with the scaling. That's just the conversion from the vanilla normals to smoothing groups when creating the ASCII breaking things. To say it is imprecise would be charitable. KBlender preserves the vanilla normals, but I don't know if Blender has equivalent functionality to Max's Rescale World Units.

You're using the Aspyr update for TSL. That's not compatible with the old exe. You'll need to switch to the "legacypc" version under the Betas tab. Right click on the game in the Library list -> Properties -> Betas, select legacypc from the drop-down menu. This will involve redownloading some of the game assets, so any mods you already installed will be nuked. If you have installed any mods, you'll want to delete your Override and Modules folders, then from the Properties menu go to Local Files -> Verify integrity of game files. After all that is finished, you can replace the exe with the WS patched one. That said, the Aspyr version should have native widescreen support anyway, so patching the exe is unnecessary. But the Aspyr version is full of bugs so it's not worth using unless you absolutely must have achievements and/or controller support.

If you want to get a better idea of what is going on, edit all the includes to change the debug logging functions to use SendMessageToPC and then recompile k_ai_master with them. The only limitation is that the feedback screen has a very small back buffer, so you'll need to be pausing every second to check it due to the volume of stuff that will be piped to it.

Something else I should address is the "direction" or "handedness" of normal maps - i.e. DirectX vs OpenGL maps. I have mentioned this before elsewhere, but for convenience sake I will recount it here. The green channel of an RGB (i.e. blue looking) normal map determines the Y direction (red is X, blue is Z) of the normal data. This is flipped/inverted between OpenGL and DirectX implementations. OpenGL uses +Y (raised details appear to rise out of the image), DirectX uses -Y (raised details appear to sink into the image). Like so: Images taken from here. Odyssey uses OpenGL, so you always need to make sure your normal maps are +Y or they will look weird in-game. You can easily switch from one to the other simply by opening the normal map in your image editor of choice, going to the channels, selecting the green channel and inverting it. If we do another test example: You can see we can easily switch between the two with a simple Y flip: Just make sure that if you are making normal maps for KOTOR that they look like the one on the left and not the one on the right.

PS isn't really of any relevance to this. You can use Gimp or whatever other image software you're familiar with. Actual generation of a normal map is done in other programs, as described in my post. Or via an online tool, as linked.

When talking about normal maps for 3D models like weapons, armour, placeables, etc., generally the "correct" way to do it would be to generate the map from a high poly version of the model. This is what is known as baking. In modern texture generation, this is often as much for creating the diffuse texture itself in the first place as it is for use with the final game model. Here's an example from some of my own experiments with recreating the Ebon Hawk textures from scratch. Take LEH_grwall01. This is the vanilla texture on the left, and my recreated texture on the right (lacking a grime pass): I started by creating a 3D model of the original texture, like so: This was the high poly model. The low poly model was a simple flat plane of two triangles. When baked out, this was the resultant normal map: Obviously this approach is not always practical. Sometimes you'll want to generate a normal map directly from a diffuse image, which I gather is what you are primarily interested in. The simplest route is to create a greyscale height map. At its most simplistic, this would entail desaturating the source image and then running through any number of programs or PS filters to generate the normal map. For example CrazyBump, AwesomeBump, xNormal, etc. There are also some online tools to do this, for example NormalMap Online. Results through this approach will vary wildly depending on the quality of your source image. As an example, let's take one of the texture sources from Sithspecter's "High Quality Blasters for Modders" modder's resource. We'll take w_blstrpstl_001 and simply desaturate it to create a pseudo-height map. Then we'll feed this into NormalMap Online: This is only about 30 seconds of effort, but the result isn't too bad considering. However if you have a look at the attached normal in closer detail, you'll see a lot of noise. This is typically very bad in a normal map, and in this case is somewhat exacerbated by NormalMap Online's lack of sufficient adjustment parameters to mitigate it. But really the root of the problem is that a diffuse is an extremely poor input source, especially in traditional textures that include baked/fake shadowing and highlights/specular. You can see in SS's source image that there are some highlights across the top of the main body, on the top of the sight back piece (bottom left corner), and along most curved edges. There is also a lot of noise in the flat areas from what I gather is the use of PS's Clouds filter, particularly noticeable in the trigger guard and surrounding area. Fortunately in this case we have some ability to quickly and easily tweak the height map, since SS's source is a layered PSD. Turning off a few of the noisy layers to create a new height map input, the revised generated normal looks like this: Looking at the attached revised normal, you'll see there is now far less noise, giving a mostly crisp map. There's still a little bit of wonkiness due to the highlights - notably at the top edges of the grip/handle, the lens of the sight (top left), and the screw heads and scallops - but that's part and parcel of using this sort of image as a source. Those particular issues could be reduced or resolved with some manual adjustment of the height map. Just imagine it as a gradient where white is the highest point and black is the lowest point. The thing to keep in mind with Odyssey is that its normal map implementation is pretty terrible. It's rarely worth the effort to create normal maps. I certainly wouldn't bother for anything small, like weapons or the like. Large floor and wall panels is probably where it will be the most notable, and these have the added benefit of typically being fairly simplistic in terms of the height details, meaning they are easy to create height maps for. Armour and bodies (like droids) can also make use of them, although this is best reserved for large details rather than lots of noisy fine detail. If you are thinking of trying it for stuff like monitor panels and the like I'd suggest you don't waste your time. Especially if it is going to be in a dark area (like the Hawk's cockpit). Stick with faked details in the diffuse for that sort of thing. Edit: Still far from perfect, but here's a further quick adjustment of the height map to address some of the highlighted (no pun intended) problems: You'd actually want to vary the height of the straight panel lines I think, make them a dark grey rather than black like the scallops. And the top edge of the handle needs to be a gradient to get a nice smooth curve. Same thing for the scope lenses (see the screw heads). w_blstrpstl_001_Generated_Normal.7z w_blstrpstl_001_Generated_Normal2.7z w_blstrpstl_001_Generated_Normal3.7z

If they don't actually do anything animation-wise, you could combine them into a single model and switch between the variant via animation state.

No, not for the main purpose TSLPatcher is designed for. As the name suggests, patching is its primary function, allowing multiple mods to edit the same files rather than hard overwriting them. It ensures compatibility for things like 2DA edits/additions, changes to GFFs (UTCs, UTIs, etc.), additions to the TLK, module injection (for GIT/ARE/IFO changes). Not natively, since it's a Win32 binary. But you should be able to via a wrapper like Wine and its ilk.