DarthParametric

Is there some sort of global plot flag that sets her to hostile? An errant UTC perhaps?

Presumably to avoid screwing with the level more than is absolutely necessary (and thus maximising compatibility). Btw, perhaps we should have a mod/admin move all this lot to JC's WIP thread. I've hijacked what is notionally a mod release discussion far more than I intended.

I've never had it happen to any files I have converted. Based on hex comparisons, Gimp does something non-standard with its TGA exports that not everything likes.

For sabers, there is a 2DA file - upcrystals.2da - that controls which crystal/blade colour gets assigned which hilt model. The most basic saber mods just replace the hilt models, so all blue saber blades will be X hilt, all green saber blades will be Y hilt, etc. With an edit of the 2DA, you can add a custom crystal with its own unique hilt model. These can remain independent of the default sabers. Any newer saber mod that uses TSLPatcher will typically be of this variety. Seeing as sabers are typically the starting point for many modders, there are a number of tutorials around that detail how to create custom sabers. Try doing some Google searches, particularly for pages from lucasforums.com. Here are a few things to get you started: http://www.lucasforums.com/showthread.php?t=143991 http://www.lucasforums.com/showthread.php?t=199293 http://deadlystream.com/forum/topic/3268-bundle-tutorial-lightsabers-and-droid-armors/

Blasters should typically just require the model (MDL and MDX files), textures (TGA/DDS and TXI files) and item file (UTI). You can add them to your inventory via console command or KSE. You'll likely run into trouble with saber mods that use custom crystals, as they will need a 2DA edit. Basic hilt overrides will be ok though. In that case they will be the same as blaster mods. You'll need to edit the UTI of any item you want to change the stats of. KOTOR Tool works for both games and is the easiest way to handle UTI edits.

A trigger maybe - to_403.utt - ?

Yeah I already made a walkmesh to stop you clipping straight through the hull, it just needs tweaking a bit in a few spots. As to the clicky thing, not sure how the position for that is set/defined. It could be tied to the look-at hook possibly, will have to try moving it around and see what happens.

The mesh needs to be brought forward a metre or two and have the walkmesh adjusted. I wasn't able to reach the clickable area to fly back to Dxun in the current position, but I think I can get it to line up with the indent for where the cockpit access is. I was actually thinking I could put some walkable boarding ramps next to it, so you could climb right up to the cockpit. I originally had the canopy up, but it clipped through the roof so I closed it for those pics seeing as you couldn't see into the cockpit from down on the ground anyway.

Interestingly, if you convert them to Bioware's DDS format things take a decidedly psychedelic turn: Gimp (?) is certainly doing something non-standard.

Horrors beyond human comprehension.

I'm still scratching my head over it. From what I can see, bytes 9 to 12 of a TGA header should contain the X and Y co-ords which determine which corner to use as the origin, but both Circa's original files and ones exported from PS just have zero values for those bytes. Maybe there is something else somewhere in the file that tells the game - or more probably the video card - to flip the texture the right way.

So it looks like it's the format they are saved in. Those are Type 10 (run-length encoded true-color image), whereas in Photoshop you'd save those out as Type 2 (uncompressed true-color image). It seems like they actually do show up the right way in-game though if kept as Type 10. According to the specification there is a field for specifying the X and Y origin, thus determining which way is up, so I imagine that Gimp or whatever is spitting these out just flips it upside down for some reason. Odd though that PS doesn't seem to detect that and display it the right way. So long story short, they appear to actually be OK as-is for game use, but you may have to flip them if you are modifying them for your own use.

Yes, both the face and clothes textures appear to be flipped vertically. They'll need to be flipped back to work properly. I'm not sure why this happens. An artefact of whatever tools they are using I guess. I know Jorak at least uses Gimp, could be related to that perhaps.

It's instructive to look at some mods by other people as to how to implement it. The manual is a bit vague about it, and ChangeEdit doesn't actually have any provision to do it automatically. Generally I find it easier just to manually insert memory tokens by edit8ng the INI in a text editor.

No, it's a simple hack job for your request. It's not in a proper state for a wide release.

The problem was the diffuse/ambient override settings for the textures. By default, NWMax doesn't expose these values for skinned meshes, only trimeshes. I forgot to edit them manually in the ASCII after exporting, so they used default values which effectively set the brightness of the textures at around 50%. This was affecting the hair as well as the face. Fixed and recompiled: I've updated the mod file, redownload it from the link I posted earlier. I also included the dark hair texture from my original bearded mullet man mod, as seen in the above pic.

Looks like it didn't survive to the files being transferred to Gamefront, but Kainzorus Prime is a member here - http://deadlystream.com/forum/user/11282-kainzorus-prime/ It doesn't look like he has uploaded the mod to DS, but perhaps you can enquire as to the possibility.

I'm not sure that it precludes the same problem from occurring. There's nothing that says DeNCS can't have more than a single fail state.

TSLPatcher creates a backup folder in the mod directory where it places original copies of any files it overwrites. You can simply copy and paste the 2DA files in that folder into the Override to revert one step backwards, but if you have run the installer multiple times then you will have lost the original copy of those files. And if you need it: Soldier is large, I think scoundrel is medium, and scout is small, going by vanilla standards.

I assumed by "added another head" that you meant you had installed the mod a second time. If not, then yes, the mod creates a new head, it doesn't override PMHC01. It's the only practical way to implement it. If you are in the middle of a playthrough you'll have to change your appearance via KSE.

Once it is installed you just edit the TGAs in the Override folder, you don't reinstall the mod. For the hair colour, just take your desired version of PMHC04.tga from my original bearded mullet man mod, rename it DP_Mullet.tga, and put it in the Override folder, overwriting the one that is there.

I've done some cranial surgery and merged the meshes together, but you - or someone else - will have to add the beard. Note that because this is a quick hack job, Dark Side transitions are not possible due to using two separate textures. To use DS transitions would require remapping all the meshes so everything fits onto a single texture. You still get DS pajamas though. And because my laziness knows no bounds, I just reused the portrait from my bearded Mullet Man mod, so you'll probably want to replace that as well. http://dpmods.wheb.org/files/kotor/k1/%5BK1%5D_Super_Mullet_Man.7z Edit VP_RevanFace.tga to add a beard. Hair colour can be changed in DP_Mullet.tga (use PMHC04.tga for original source). The portrait is PO_SuperMullet.tga. The easiest solution would be to just use the face texture from that bearded version I linked to above. Rename their base texture PMHC01.tga to VP_RevanFace.tga and dump it in the Override (or tslpatchdata in my mod folder before you run the installer), overwriting the original. Acknowledgement and attribution goes to VarsityPuppet for his PMHC01 modder's resource. This mod uses his model and texture.

Someone already did a bearded version of VP's head, but still has short hair - http://www.nexusmods.com/kotor/mods/77

Changed the AuroraBase name. If you look at the original MDL in your hex editor (and probably decompile it in MDLOps so you can look through the ASCII file in a text editor), you'll see there are two instances of "I_Mask_011". The first is the name of the AuroraBase, and the second is indicating that it is the parent of trimesh VerpineHeadBand. I simply replaced both those instances with "I_Mask_088".

Whoops, wrong sub-domain. Works now.