DarthParametric

A quick Google and here's the thread in question - I'm not sure that it was ever formally released, so you may want to poke @bead-v about its status and getting hold of a copy. Edit: Thread necromancy wasn't quite the type of poking I had in mind.....

There's probably a strong argument to keep it pre-rendered just because even if you could jam everything into a single module, there's no way to do the transitions in-engine. With that in mind, you should look into that camera track generator that I seem to recall @bead-v was working on at some point. That would allow you to do those same rotating shots around the star maps as in the original video.

To be honest it would probably be quicker for someone just to do it for you rather than try and guide you through the process step by step if you've never played around with level editing before. And as I alluded to above, I'm not sure how feasible adding the exterior Dantooine shot would be. Edit: And Manaan as well is pretty open. Perhaps you could make a thread somewhere - WIP forum maybe? - and break down every shot with details of the location. Module names, NPC and camera co-ords, etc.

The problem is more the inconsistent size/scale of the head meshes. They vary fairly wildly, which is not ideal when making use of static masks/goggles, even if you went to the trouble of manually tweaking the hook position for each one.

You could just do exactly what the game does for such cases, and have all the different areas as hidden rooms in one module. Although that might be a stretch if you want to keep Bastila on Dantooine.

??

Here, I whipped one up for you: https://www.darthparametric.com/files/kotor/k1/[K1]_Invisible_Disguise.7z Just install it and then add it to your inventory via KSE (or console command). It's a belt, item resref is g_i_belt123.

Ah, machinima. I assume you are puppeting it all manually in that case then rather than creating cutscenes? As I said above, the model needs to be recompiled for K1 in order for it to work. You could just create a new invisible model, since all you need is a rig with no visible trimeshes (and presumably no shadows enabled). Either way, if there is a proper row for it in appearance.2da then it should work.

If you want to turn a player invisible, that's really not the ideal way to go about it - in either game. What is it exactly you are trying to do?

You need to create a new row for it in K1's appearance.2da, copying across the appropriate values from TSL (bearing in mind the differences in columns). I gather you have already done that part. Then you need to create a new UTC for it. You can do this by duplicating an existing K1 UTC, changing the appearance, giving it a unique resref/tag, giving it appropriate feats, editing the inventory, etc. Look at c_lightsaber004.utc in 907MAL to see what Obsidian did. After that, you'll need to add it to the module's GIT to make sure it spawns in the module. Depending on what you want it to do, you may also need additional scripts and/or dialogues.

The floating lightsaber is just a rig with animations, essentially an invisible hand. Treat it like any other creature or NPC. It needs a UTC with a lightsaber equipped on its paperdoll. And of course you need to recompile the model for K1.

There's also this one:

Another breath mask option: There's a lot of fixing required for some of these due to backface culling issues.

Well it appears to be a greyscale bumpmap - albeit an odd one - rather than a tangent space map, but it converts to RGBA with a transparency mask in the alpha. But neither the diffuse nor bump have any TXI data that I can see. It was pointed out to me by @Salk in this thread. I believe I did mention it to you in a PM at some point. LKA_leaf01.7z

Ah. I wasn't sure if the pics were before or after. But I guess I gave you a couple of fixes to add for the next update.

And what exactly are said fixes? From the pictures I imagine something like: Removing Manaan airlock transitions Not highlighting new items in inventory? Fixing UV seams on random pipes on Tatooine? Czerka office? Making the alien hating guy on Taris a human? ?? No idea Turret sides don't extend to the edge of the screen in widescreen

So you're saying it doesn't ever make use of an alpha mask for transparency, even though there's at least one vanilla normal map with an alpha mask? Although the map in question appears to be unused in the actual game, at least judging by the TXI semantics of its parent diffuse.

Looking at the version I have here (v13), the left hand and thumb and the right fingers have inverted UV faces. As do the left arm, chest, right leg, left boot upper, right boot lower. Although the left arm is intentional presumably, as it shares UVs with the right arm. Edit: The boots are also overlapping, I'm guessing probably the original UVs? That sort of weird half and half inversion is typical of vanilla UVs.

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).