DarthParametric

Bearing in mind that, again, jumping into heads is not recommended if you have no experience with this sort of thing, I'll give you a brief overview of how to go about it. You'll need to do some research yourself to fill in the blanks. Seeing as I don't have your head, I'll just swipe one from an existing model to use as a roughly equivalent example. We'll take the TSL Ithorian: And lop off his head. Then trim off the excess bits and straighten the neck out a bit to approximate what you have, like so: Now before we get to skinning, your first problem is going to be that your head mesh isn't going to match any of the body meshes. They are all designed to mate perfectly with a human neck, so by just plonking on a giant alien head you are going to wind up with clipping and/or gaps. You could try making some sort of intermediate collar piece to slot between them to mask the join. I've done a quick hack job to show the sort of thing I mean. Start by loading in a human head to use as basis: Duplicate the head mesh itself, and isolate just the neck element, deleting the rest: Now I'm not going to cover modelling and UV mapping, so the short version is reshape this so you have something collar-ish like, making sure to not touch the bottom ring of verts, as these match the body meshes. And with the Ithorian head positioned appropriately: Note that if you move your mesh around, you'll need to do a Reset X-Forms on it and collapse the stack before proceeding further, otherwise you will run into issues later. Now we can get on with skinning. As I said in my previous post, the human rig is not going to be compatible with radically different alien morphology, so this will be limited to just a few bones, namely the head, head_g, and neck, neck_g and necklwr_g. Here is how my Ithorian head is positioned in relation to the human head: Based on that, we can use Edit Envelopes on the human head mesh's Skin modifier to see how these bones influence that mesh: Vertex weights are 0 to 1. Enabling Edit Envelopes will shade polygons based on the weight influence of surrounding vertices, with red representing weights approaching 1 and blue approaching 0. Weights on a given vertex can be split between multiple bones, but they will always add to 1 (so increasing the influence of one bone will decrease any others). Based on the position of the Ithorian head, the majority of the mesh can just be weighted 100% to head_g, with the lower neck getting a small influence from neck_g and necklwr_g. Simply adding a Skin modifier and adding head_g, neck_g and necklwr_g to the bone list should give you a pretty good starting point, as Max tries to allocate appropriate bone weights automatically: In this case though, the influences of neck bones seems to be a bit off, so I'll tweak that slightly. I'm not going to explicitly cover how to weight verts here, there are plenty of Max tutorials on Youtube and elsewhere that cover the process. Google is your friend. The process is the same for the collar, just with more weighting to the neck bones, noting especially to set the bottom ring of verts 100% to necklwr_g so they match the body model. Note that this will be something of an incremental process. You'll likely need to do a few passes making adjustments after testing it in-game. In certain cases with custom meshes you may also need to add additional loops to allow for smoother deformation, but that's generally more applicable to body meshes. With the initial skining pass done, we can move to finalising a few other things before export. You can delete the original head mesh. Things like the eyes and eyelashes are technically bones, so you may want to just turn off the Render option in their AuroraTrimesh modifier. You'll likely want to select everything in the scene aside from your meshes and remove any existing materials they have (Utilities pane -> More -> UVW Remove -> Materials). With a giant head like this you aren't going to be able to diplay the models for masks/goggles without horrible clipping, so delete the helper objects MaskHook and GoggleHook. Make sure your meshes are children of the AuroraBase. Select the AuroraBase and rename it to something appropriate and unique. I named mine DP_IthorianH. In the Modify pane turn off Do Sanity Checks and set the export directory somewhere appropriate. Hit the Export Geom Only button. You can save and close your Max scene. Find the exported MDL and edit the filename indicate that it is an ASCII file. For example I named mine DP_IthorianH_ASCII.mdl. Now you'll need to get hold of a binary model for MDLOps. Typically I use whatever the Supermodel specified in AuroraBase is, which in this example is S_Female02. You need to use the model for the version of the game you are compiling for. In this case I will be compiling for TSL, so I grab the TSL version of s_female02.mdl and s_female02.mdx and place those in the same folder as the ASCII model. Then those need to be renamed to the same name as the final version of your model. In this example, that is DP_IthorianH (hence why you append _ASCII to the ASCII file's filename). Now you can run MDLOps and load the ASCII file, then hit the Read and Write Model button. Once it is finished processing you should have a new binary MDL/MDX pair in your folder, in my case DP_IthorianH_ASCII-k2-bin.mdl/DP_IthorianH_ASCII-k2-bin.mdx. Now you need to take these and run them through VarsityPuppet's HeadFixer tool. This will patch the MDL, after which you can discard the old one. So now you have your head model, which you can rename as appropriate (I changed mine back to DP_IthorianH.mdl/mdx), it's time to get it into the game. The prefereable method is via TSLPatcher, which I am not going to exhaustively detail here. Suffice it to say, you'll need vanilla and modified copies of appearance.2da, heads.2da, and portraits.2da. The modified copies contain your additional rows, and you can then use TSLPatcher's ChangeEdit utility to difference them with the originals to generate the appropriate data in changes.ini. You'll also need to add in memory tokens, which I generally find quicker to do by editing the INI directly in a text editor. I'll post the version I threw together for you to look at. Once you have it installed, it's time to fire up the game. Cue drum roll: OK, so that looks hilariously bad/ridiculous. I guess that collar needs some work. But the model does otherwise work, so mission accomplished on that front at least. Here are some resources, if you want to poke through them: ASCII model - http://dpmods.wheb.org/files/kotor/misc/DP_IthorianH_ASCII.7z TSLPatcher setup - http://dpmods.wheb.org/files/kotor/tsl/%5BTSL%5D_Player_Head_Ithorian_Test.7z

Not true, I've done it for instance. It's entirely possible, although success is largely down to whether MDLOps decides to co-operate. I would suggest if you are not familiar with rigging/skinning, heads are probably not the place to be starting. However, in this case you will be stuck with something very simplistic anyway, as the human rig is not going to accommodate something as weird as an Ithorian. Just weight all verts 100% to the head bone.

The supermodel for Juhani's head is P_JuhaniBB.

Yeah it's pretty much a case of which issue is less egregious? I probably won't bother ever using custom sabers in TSL again, or releasing any more saber mods. I reported the issue to Aspyr, but it doesn't seem they are going to do anything about it (I'm not even sure if it got past the support monkey reading the ticket).

You have to change it to Disable Vertex Buffer Objects=1in order for it to work. It happens with all saber types.

My 2¢ - perhaps some scavengers could set up a space station near the ruins of Peragus for the purposes of combing through the wreckage. Could be various valuable minerals, etc. You could maybe have something similar to the quest in K1 where someone, pirates or mercs, try to take the place over. Or maybe in a turnabout you could help the pirates take over.

It's not two sabers, it's the texture disappearing/being rendered flat. It's a bug Aspyr introduced. Only known fix is to disable vertex buffer objects in the INI.

It was just laziness - or expediency if you prefer, I guess. It's one of the Sith monument placeables, plinths and pillars and such. It would be easy to replace it with a new model. Just point the UTP at a new custom entry (I gather the existing model is reused elsewhere, so I wouldn't override it). Put a regular size holocron on a table, maybe give it some animated glowing light textures or something to make it obvious. Edit: Whipped a new model up for you if you want to use it. You like texturing, right? If you wanted to take the holocron with you, I guess you could maybe use a script to swap between 2 different placeables? One a table with the holocron, one just an empty table? Or have the table and holocron as separate placeables and use a script to remove the holocron. Then just do the same as they do with the Nihilus mask for the inventory. Too bad you don't have proper quarters on the Ebon Hawk (where do you sleep, anyway?), otherwise you could display it there.

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.