DarthParametric

If you changed the texture to include a larger number of frames, you might be able to introduce a bit more "noise" to emphasise that it is a hologram. If the sequence was long enough, you could have it briefly disappear altogether, although that might be a bit too epilepsy-inducing in a short sequence. I never really understood why they made it 5 feet tall. I always thought it looked ridiculous. There must be better ways of drawing attention to it.

Yeah if you edit the alpha channel to dampen the level of transparency that might help with the visibility of sub-meshes a bit, but it's always going to be a problem with such a simple implementation. There's the scanline effect that makes it a bit variable, but it looks like it is hovering around the 50% transparency mark.

In the TSL version (nothing in K1) there's VFX_DUR_HOLO_PROJECT which references the model v_holo02_dur, which is an emitter with no reference to any textures. The emitter is 1.7m in the air and pointing forwards and slightly down, so I assume it is used by a droid of some kind. Maybe it is for the G0-T0 droids?

Not sure where exactly the hologram effect is defined, but the texture is "Holotex" (512x128) and it has the TXI: numx 4 numy 1 proceduretype cycle fps 15

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.