DarthParametric

Sure, but my preference would be to teach and encourage best practice for people new to the concepts. Once you know what you are doing, you can do as you please, but if you learnt how to do it properly then you are less likely to half-ass stuff you release.

Removing the Zabrak sub-species is just the first step. You also need change all the models and textures specified in his appearance.2da row to point to the regular male bodies.

I find putting a GIT in the Override causes issues. I prefer to just do it properly from the get-go.

I think she's using the "dead3" animation in that scene? I don't have a convenient save to test with, but try this and see how it goes.

The model is not specifically relevant for what you want to do. You don't need to extract the model or textures, unless you plan on making a custom version. To start with, you'll need a UTC which points to the existing entry in appearance.2da (Alien_Bith_01). You can use the Taris one you extracted as a starting point, but you'll need to change a few things. The Tag and ResRef for instance. You'll also need to change the references to two module-specific scripts it uses, OnSpawn k_ptar_dancer_sp and OnUserDefine k_ptar_bith_ud. You should just be able to extract those two scripts from the Taris module and rename them, then point the UTC to them. Someone else may want to check, but a cursory glance suggests they shouldn't need changing. Then you'll need to add the new NPC (or NPCs) to the destination module's GIT, under the CreatureList. This defines the position and orientation of the NPC in the module. Depending on how you prefer to work, you may find it easier to determine the location directly in-game via an armband, or load up the module's models in Max/GMax. You'll need to create a MOD file to inject your changes/additions into. To start with you can just brute force edit everything, but if you plan on a public release you will want to use TSLPatcher for compatibility. That should be the bare minimum to get you going. Keep in mind that GIT edits won't work with existing saves, so for testing you'll need a save before entering the target module for the first time.

So, what fabulous prizes do I win? Credits, spice, Twi'lek slave girls?

As I said above, it works for the FullName crystal: There's nothing special in the UTI. I suppose it's always possible it was hard coded, but I'm sure I have seen FullName used in other UTIs.

<FullName> should work. That's what is used in your pet crystal's description, for example. Maybe the comma is throwing it off? Seems unlikely, but try it without or with a space between them.

The value for Clamp should be the maximum pixel width bleed I believe, so -1 is presumably not a valid number. I'm unsure about 0, but it seems like your test would indicate that is also invalid.

What you want is just a simple appearance.2da edit. You can easily change any or all armour classes to display the underwear model (or a different model, like the Twi'lek body).

I assume you mean it doesn't like TGAs, which is to be expected. If ndix UR can implement swizzling in TGA2TPC then it should be a non-issue. I'm not sure the effort would be worth it though, so don't hold your breath.

I would suggest you use CODE instead of bulleted lists. Preview the post and then change AUTO to XML so you don't get the technicaolour nightmare. Code = Auto: Line 1 Line 2 Line 3 Code = XML: Line 1 Line 2 Line 3

Have you tried going the opposite route? For example, scaling your image down to 2046x2046 on a 2048x2048 canvas, then using padding to fill in the dead pixels? I believe xNormal has a plugin that will do the padding.

Hah, what the hell. Which specific module is that?

Did you try using Clamp 1 instead?

Yeah, you specify both together, like so: bumpyshinytexture CM_baremetal bumpmaptexture TextureNameB

Any head that uses Dark Side transitions will have its textures overridden, so you can't use two separate textures and keep DS transitions. You either have to choose to have no DS transitions, or you have to merge your changes into a single texture (and create matching DS textures). Assuming you have overlapping UVs and you can't simply copy and paste the relevant bit of texture over the top of the original, they quickest and dirtiest approach is to tile the UVs and create a single side-by-side texture from the two different head textures. Like so: You may want to watch this: The UVW Xform Array Helper script is what I use to automate the process - https://mariokart64n.deviantart.com/art/Uvw-Xform-Array-Helper-608086399

I believe the mipmap semantic forces the game to always render the stated mip level. So you can force the game to always show the highest mip, even when it is far away, for example. A couple of other options for bump/normal maps: isdiffusebumpmap 1 isspecularbumpmap 1 Which notionally should allow for something like the opposite of bumpyshiytexture, but I haven't experimented much with it. A more specific example for proceduretype cycle: proceduretype cycle defaultwidth 256 defaultheight 256 numx 3 numy 2 fps 12 You have to specify the dimensions of the image, how many frames that image comprises, and at what framerate you want them to play.

Well the "proper" way that you would create a player head mod for the PC version involves editing appearance.2da, heads.2da, and portraits.2da (in addition to the head model and textures, but you can use the vanilla ones for Bastila). I have no idea what the deal is with Xbox 2DAs, whether there is some big endian/little endian thing going on. You could try going that route first, although it would require extracting them from a BIF, presumably. If the Xbox data is anything like the PC, they should be in a file called 2DA.bif. You could try copying that and the KEY file (probably chitin.key) to your PC, then extracting it with unkeybif.exe from Xoreos Tools. Then you could use convert2da.exe to convert the required 2DAs to CSV. Then you would follow any standard "adding a player head" type tutorial to add the new data, then use convert2da again to convert the CSVs back to 2DAs. Then you'd transfer the modified 2DAs back to the Xbox, putting them in the Override folder. Like I said though, I don't know if Xbox 2DAs are different from PC 2DAs, so I have no idea if that will work. Assuming that doesn't work, the other option is the more brute force route, replacing one of the existing player head models with the Bastila head model (P_BastilaH). This will require changing the Odyssey Base name, the quickest route being to decompile, edit the ASCII model, then recompile. MDLEdit can handle Xbox models, so that should be fine, although you'd presumably want the Xbox supermodel (P_BastilaBB). Those should also be in a BIF file. You'd also need the Bastila head textures, which are in ERFs on the PC version, not sure for the Xbox version. I'd suggest trying the 2DA route first though and seeing if that works.

If you are using the old version of MDLOps you need to use HeadFixer to patch the resultant binary model. The latest version of MDLOps and MDLEdit have built-in functionality to sort it out.

Yes, I didn't say that the fog fix would solve your problem. I said the issue was related and you'd probably need the same sort of shader hack to fix it. You'd need to sort it out yourself by using the fog fix as a basis. Alternatively, sELFiNDUCEDcOMA apparently has some secret fix for the lightsaber bug, which might be applicable - http://deadlystream.com/forum/topic/2062-tsl-textures-remastered/?p=62552

If it's an NPC head then all you need to fill in (aside from the model name in "head") is the "alttexture" column with the value for your new texture. It should be noted however that this only works in TSL. In K1, you would need a new head model, as K1's heads.2da lacks the same base texture override.

That just adds a clamp semantic to a TXI. It's not the issue here. Your best course of action would to either give the existing sphere a new UV layout more suited to what you have in mind, or outright replace the mesh with something else.