DarthParametric

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.

You're already doing a distance check, which would be what I would fall back to as a poor man's proxy.

My own limited experience with it was not successful. One of the vanilla Xor scripts relied on it, which was probably one of the reasons why he was so broken.

Yeah if you are already editing the entire party's UTCs then it's six of one, half a dozen of the other I guess.

He's checking for when the rest of the party is dead while Mission is still alive, so that would require adding OnDeaths to everyone else.

Since you clear it out of combat, you could just go with permanent. Something you'll need to test I guess. Another thing that springs to mind is that you'll probably need a GetIsDead check in addition to or as opposed to the GetIsObjectValid check, much like that Xor mooks issue for K1CP. Especially with party members, they presumably remain a valid object after death, since they resurrect after combat is over.

Not sure about the duration type, since I haven't messed much with that sort of thing besides some cutscene-related stuff.

You'll probably need to edit k_hen_damage01 and do a HP check. They don't have an OUD or OnDeath script assigned aside from Canderous, who has an OUD with an OnDeath event for his regen.

It wasn't a stylistic choice, it was a performance optimisation. I very much doubt Bioware's original vision for the game was characters looking like they were taken straight out of the original Tomb Raider.

The other thing you can do is add the emitters that the regular door forcefield has (check the "mydoor2" door model) to each side. I didn't add them to the Leviathan field because it was too big, but maybe the Manaan/Yavin hangar opening is small enough that you won't need too many duplicates. Plus you don't get to wander around the Leviathan hangar anyway, so there wasn't much point.

Well I stand corrected then. I'll have to make use of it in the next K1CP update to change some of the existing hacky workarounds.

You'll still see UI notifications and feedback messages for gained/lost items. If it is really important and it involves a party member, you can temporarily remove them from the active party to do whatever you need, then add them back. Although typically you want to do this under a fadeout/during a cutscene.

The remake is in UE4. There won't be any NWScript in it. It doesn't even use UnrealScript any more, just Blueprints. If you are giving up, then please at least make the current source code available. DS now has its own Github repo for various tool projects. If you'd like to create a repo for it there, jump on the DS Discord - https://discord.gg/h68Z9Ds2 - or send me a PM.

Not in K1. You can in TSL, since Obsidian added an extra variable for suppressing those messages.

No. The debug features require the debug build. We have the shipping build in which all the debug features were stripped out. However, there is the SendMessageToPC function, which pipes strings to the in-game message window. You can make use of this for script debugging functionality, although the message window buffer is very small, so during combat especially you will find your messages quickly disappear. Armbands that provide location info (like the WhereAmI armband) are a good example of the use of SendMessageToPC. You can also edit the various debug include functions and switch out their use of PrintString/AurPostString to use SendMessageToPC, then recompile the target script/s.

A module's IFO has provision for specifying OnXYZ event scripts for most of those, although I don't know how many of them actually function aside from the specific module events, since most are left blank in the vanilla modules. Odyssey has a lot of leftover Aurora (NWN) stuff.

This is a known issue that requires Sithspecter to upload the fixed version of the Revan model.

As far as I know, the party selection screen is the only GUI to have something like that, but even then only when opened via script in the first place (the ShowPartySelectionGUI function allows you to define an exit script).