DarthParametric

You have to decompile the scripts yourself. That snippet is from the decompiled on-enter for TAR_M03AE (Javyar's Cantina). You'll want DeNCS for that - http://www.starwarsknights.com/mtools/DeNCS.zip I would suggest creating a duplicate copy in a separate folder and using K1's nwscript.nss for decompiling K1 scripts.

You'll probably need to add to the module's on-enter script. Something like this: sub3(OBJECT_SELF); oAreaObject = GetFirstObjectInArea(OBJECT_INVALID, 64); while (GetIsObjectValid(oAreaObject)) { if ((GetTag(oAreaObject) == "ptar_pazplayer")) { AssignCommand(oAreaObject, ActionPlayAnimation(206, 1.0, 0.0)); } if ((GetTag(oAreaObject) == "ptar_sitter")) { AssignCommand(oAreaObject, ActionPlayAnimation(204, 1.0, 0.0)); } if ((GetTag(oAreaObject) == "ptar_drinker")) { AssignCommand(oAreaObject, ActionPlayAnimation(205, 1.0, 0.0)); } oAreaObject = GetNextObjectInArea(OBJECT_INVALID, 64); } Check the on-enter scripts of other modules with sitting placeables to see what they do. Edit: The 64 in the oAreaObject statement equates to OBJECT_TYPE_PLACEABLE. The 204/205/206 in the ActionPlayAnimation statements equate to ANIMATION_PLACEABLE_ANIMLOOP01/02/03, respectively. You'll want to check the model to see what animations it has to determine which you want to play. Edit 2: Ah, that's right, the placeable sitters are actually just standard character models. The animations are on the S_Male02 supermodel. Looking at it in Max, ANIMLOOP01 is a static sitting pose, ANIMLOOP02 is sitting and drinking, ANIMLOOP03 is sitting playing pazaak.

All your right arm UV faces are inverted, but the left arm shoulder faces are also inverted. This could be related to that, although I would have been more likely to suspect that in the case of overlapping UVs, which these aren't. As I said in the edit above, I wonder if a remap of the arms isn't worth trying.

The alpha should be solid white in your case. As far as I am aware, it is only a transparency mask (although I haven't actually gotten around to testing it with transparency). Your highlight issue would appear to be along the UV seam on the shoulder? And I gather it's the same with the wrists. Edit: How about remapping the arms something like this? Obviously ignore the scale/placement in the layout, I'm talking more about hiding the seams on the underside/back of the arm and eliminating the seam on the top of the arm altogether.

Apologies. Yes, you'll want to set the DXT5 flag in TGA2TPC. The DTX1 implementation is RGB only, hence why it crashes I would guess. I'm not sure why uncompressed would cause a crash. That would be a question for @ndix UR. Edit: Ah, you said RGB. That would likely be the problem. It needs to be RGBA. The DXT5 conversion is presumably adding an alpha if the source image lacks one. The simple trick to remember for direction is that if the detail is meant to be raised, that detail on the normal map should appear to be coming out of the screen (versus going into the screen in a DirectX/-Y map). It's often problematic when you are generating normal data from images, especially colour images. It's not uncommon to have some details being flipped in direction vs others in the same image, even when they should be pointing in the same direction, requiring manual flipping of those areas rather than the whole channel.

Yes that's outdated, erroneous information. That thread was continued here. For clarity, Odyssey requires OpenGL (i.e. +Y) tangent space normal maps with an alpha mask, formatted as a TPC. The reason the whole indexed colour thing came up in the first place was that the engine would not accept TGA (or DDS) RGBA bumpmaps, but it would accept greyscale TGA bumpmaps. People thought they could "cheat" in a normal map when it was discovered that it also accepted indexed colour TGAs, but it was proven that the game simply read it as a greyscale bumpmap, not a normal map. As I said above, ndix UR seems to have implemented an undocumented feature into TGA2TPC (or at least one I was unaware of) that converts an indexed colour image to RGB and normalizes it (i.e. generates Z data in the B channel). So that was why you got a functional map out of it. But it doesn't know what handedness the source image is. The nVidia filter is DirectX based, so it produces -Y normal maps. To switch these to OpenGL/+Y, all you need to do is invert the G channel (CTRL I in PS).

That's not how you make a normal map. A tangent space normal map is RGB (plus an alpha mask for Odyssey). If you want an actual bump map, that is greyscale. Additionally, your Y direction was wrong. See this post. It seems like ndix UR put some provision in TGA2TPC for dealing with indexed colour maps, judging by converting your original TPC back to TGA, but the Y was still inverted.

Your source normal map is incorrectly formatted. Try this and see what happens: Edit: Whoops, made a meal of the first one. 2nd attempt - Alt_JC_HandBA_B_v2.7z Also, for future reference you can dispense with the isdiffusebumpmap 1 isspecularbumpmap 1 TXI semantics. Per discussions with @ndix UR, they are leftover remnants from NWN that aren't actually used by Odyssey.

That's just more art. That doesn't advance the project, if anything it pushes it even further along the wrong path. Artists are a dime a dozen. A monkey could slap together some art assets in Unreal and call it a game (as evidenced by all the asset flips on Steam). What a game needs is programmers. If you don't have any then you shouldn't even bother starting a project. If I was going to undertake a hypothetical KOTOR remake (and let's call it what it actually is and dispense with this "mod" BS) in Unreal or other 3rd party engine, I would start with a fully functional recreation of the Endar Spire level. Forget about the art assets, simple white box mockups and default Unreal characters would suffice. What matters in an RPG is the underlying systems. If you are starting KOTOR from scratch, you need to develop a multi-node branching conversation system, equipment and inventory system, stats and levelling system, party/companion system, ranged and melee combat mechanics, etc. The Endar Spire is the perfect test level for developing and testing that. You have a couple of NPCs with a few lines of dialogue, a couple of conversations, a few combat encounters, a few cutscenes, etc. all in a very small space comprised of a few small rooms linked by corridors. And if you haven't demonstrated even a fraction of any of that after 2 or 3 years of screwing around, you should just stop wasting your time.

Lol no. They are just a bunch of kids playing around in Unreal with emissive textures. They don't actually have any ability to make a game.

Got some more, although they aren't really supposed to be used with heads with hair (but meh). And if anyone wants to make suggestions for replacements, here's a chart of what the vanilla masks look like: Edit: And a couple more to round out the evening's work:

Arcann's mask cut in half and mirrored makes for a pretty good full face mask. Or if you prefer to get your temple guard on: Although there are some clipping issues with hair on certain heads, like Hispanic Mullet Man above. Might have to play with that a bit. Edit: And to replace the Tulak Hord helmet in K1 Generally full helmets don't work too well without being scaled up to ridiculous proportions, but this was already pretty giant to begin with, so it shouldn't be too bad for a decent percentage of player heads.

Sounds like user error. Since the removal of the porting ban, I have moved models between both games and had no issues. You need to describe your workflow in detail.

Some additional masks: I still need a few more, particularly for the full face masks, but I have enough to start trying to figure out what replaces what. I plan to edit UTIs to point to the new models, rather than just overwrite the vanilla models. That will allow for swapping things around a bit. Here's how the vanilla items are set up: I figure the Eradicator mask in the first post is an obvious choice for the Sith mask, but I'm open to suggestions for which other items should get which model.

DAN_PLANET_PLOT perhaps? Or maybe LEV_ESCAPE after leaving the Leviathan? There should be something in the galaxy map script that checks whether or not you can still travel to Dantooine, so that should be what you are looking for. Edit: Looks like that script references K_CAPTURED_LEV.

Very odd, and even stranger that it should be an issue in the first place given that it doesn't exist in the P_MandaloreBB model. But problem solved I guess. Thanks for figuring it out.

No, the glow is via self-illumination, Odyssey's implementation of emissive. Similar to how emissive in other engines works, it multiplies the texture via some colour value (typically only greyscale in vanilla models, but you can use RGB values). However, unlike in other engines, KOTOR's self-illum does not make use of an emissive mask, so the entire mesh with the self-illum flag will glow. This is why you typically need to split the emissive sections out into their own mesh. That's why they came up with using CM_Bright, as an alternative way to fake emissive where the pattern is far too complex to split out as a separate mesh. But as you say, you can't combine that with other envmaps. Here's how I've done the self-illum meshes for that first visor: Only the mesh with the lights uses self-illum, so the rest of the model is not affected.

The weighting is definitely different for that torso vert in P_MandaloreBB, but I'm still not seeing how that could cause a whole poly to disappear. I'd expect a gap around the edges, but not a hole. It also looks to me like the missing poly in the pictures above is different to the one with the mismatched skin weights (although that could just be due to the pose deformation).

Depends on the specific model. Something like a mask isn't typically too much work. Mostly repositioning and scaling the mesh to suit. Although in order to make effective use of KOTOR's self-illumination for the emissive parts of the texture, extra geometry typically needs to be added. This might be editing the original mesh and then repairing the UVs, or creating entirely new meshes. This is because self-illum is set per-mesh, so unless the majority of the texture is black then the entire thing will glow. For heads, as well as repositioning/scaling there needs to be a lot of mesh work to deal with KOTOR's limitations. That means splitting out the eyes, mouthbox/tongue, and teeth as separate meshes. Then the whole thing needs to be skinned to KOTOR's rig. Bodies are probably the biggest pain, because they are in more of a modern-style A pose. So as well as just scaling, the arms need extensive repositioning to match the KOTOR rig. Once that is done they then need to be skinned to the KOTOR rig. In addition to that, a more general issue with the import scripts is that its implementation of generating smoothing groups results in a mess that needs to be cleaned up. I think this is probably due to the way the mesh is split, so the first step is welding and then re-generating smoothing groups, manually assigning them where necessary.

Cool, glad it worked for you. Although I am still scratching my head over the arm issue with the original P_MandaloreBD. Perhaps @bead-v and @ndix UR could shed some more light on it by examining the binary model.

Playing around with some of the Jedi Knight visors. I think they will be good replacements for some of the vanilla masks: I haven't adjusted the textures yet, so they are still their default (mostly) brown. I also need to add some glow meshes for the first one, like you can see in the second and third ones. I think I'll also use an envmap for the lenses, give them a bit of reflection. Perhaps the first two could also have their lenses changed from black to something more bluish like the other two.

It looks fine in Max. There are no missing/flipped/overlapping polys in that location that I can see: Edit: OK, I have replaced the torso and arms with the P_MandaloreBB versions. Redownload from the link above.

The back two are holes where the hoses from the helmet would connect, so that's expected. They would need to be manually fixed. The hole in the arm is odd though. If the back needs to be fixed anyway, I'd probably just switch to the full body model as a basis and lop off the head. Edit: Looking at the vanilla P_MandaloreBD, I don't see any missing or flipped polys in the arm (there were some duplicate polys on the back though). Try this version with plugged holes in the back https://www.darthparametric.com/files/kotor/tsl/[TSL]_P_MandaloreBD_Hole_Plugged.7z

No, there is no specific KOTORMax thread (aside from the release and support threads). It was awaiting the creation of the promised Tools subforum. Edit: This thread is still pinned by the way - https://deadlystream.com/topic/4905-mod-of-the-year-voting-2016-kotor/