DarthParametric

Yes, the texture and model variation are tied together. For example, say I want to make a different coloured version of the Verpine Headband for K1. I dig out its UTI, g_i_mask11.uti, and change it to a custom variation number, let's say 75. So I change the ResRef and Tag values to g_i_mask75 and the model variation to 75, then save that as g_i_mask75.uti. Extract its icon texture ii_mask_011.tga. Edit the icon as appropriate and save it as ii_mask_075.tga. Then extract the model, i_mask_011.mdl/mdx. You can look at the binary MDL in a hex editor, or the easier route is to decompile it and open the ASCII model in a text editor. You'll want to change all instances of I_Mask_011 to I_Mask_075. You'll also see that the texture is I_VerpHBnd, so change all instances of that to whatever you want to call your texture. If you are hex editing you'll want to keep the same number of characters, but if editing an ASCII you can change it. For example, I would use something like I_DPHBndA. Then save if you are hex editing, or recompile if editing an ASCII. The model's new filename would be i_mask_075.mdl/mdx. Extract the model's texture, I_VerpHBnd in this case, including the TXI if appropriate (KOTORTool has an option to also extract a TXI). Edit the texture as you see fit and then save it as whatever name you specified in the model, I_DPHBndA in this example, and likewise rename the TXI if appropriate. Put all the files in your Override, add to your inventory with KSE, and load up the game to test: It's the same for TSL, except some of the filename formats are different.

Match your texture variant number to whatever you put in the UTI.

OK so upon further testing, it appears that I am suffering from a random crash on loading character creation that is unrelated to this issue, as I can induce it independently. So scratch that off the list. Additionally, I have also established that the problem is unrelated to UV changes/vert count. Basically the changes you introduced to fix the skin weight/node assignment issues in certain vanilla models now appears to cause that very same problem to occur in other models. To expound, take a vanilla model and simply decompile it, then recompile it. It should work fine, like so: 01_PMHC04_Edit_Initial_Compile.7z But if you take that 2nd generation binary model, decompile it and recompile it, you get something like this: 02_PMHC04_Edit_Decompile-Recompile.7z If you look at the ASCII of the 2nd one, you'll see the skin weights assigned to wrong nodes issue, as I showed in my previous post. If, however, you decompile and recompile the 2nd generation binary model with one of the older builds of MDLEdit like v0.5.0, you do not get this issue. Skin weights remain intact on subsequent decompiles/recompiles. 03_PMHC04_Edit_0.5.0_Decompile-Recompile.7z

I wasn't talking about creating a new cube map. I was explaining how you use an existing cube map to make your new texture shiny.

PMHC04 from TSL, but the vanilla model is fine. The problem is with a modified version of it, as described.

It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet). On trying the old decompile/recompile trick, skin weights are being assigned random non-bone objects much like the issue with vanilla models above, like so:

Cube maps are the envmaps, CM_Baremetal and so forth (that's what "CM" stands for). If you want something shiny, you paint those areas dark in the alpha channel, effectively making the texture transparent in those areas and letting the envmap show through (as long as you specify an envmap in the TXI).

Subscribe to TSLRCM on the Workshop first, then subscribe to M4-78. After that, manually install all your other mods to the M4-78 Workshop folder.

There is zero difference in how you texture a KOTOR non-level* model regardless of whether it is a prop, a weapon, a body, a head, etc. RGB diffuse and alpha for either transparency or cubemap blending. The only change is now with the new tools you can additionally make use of a tangent space normal map, but again that applies to everything. *And even in the case of level models, the texturing itself is no different, you just need a second non-overlapping UV set to bake your light maps.

I remember playing around with those scripts years ago to swap in training sabers: The two I edited were k_pdan_cut01 and k_pdan_cut06, although I didn't add in any alignment checking to mine. I would think one issue for the player could be lack of the saber proficiency feat, but that shouldn't affect Bastila. Did you try just a simple swapping out of the UTI reference and none of the alignment checking to see what happens? To expound on what Kexikus seemed to be suggesting, you could create a "prop" saber item that doesn't require feats to use by extending baseitems.2da and see if that works.

The problem is buggy code Aspyr added. The only proper solution is not to use their version (i.e. revert to the "legacypc" version in the beta tab). There is no way to fix it unless Aspyr themselves do it.

3 hours for someone to comment on it, but given you're pretty much the only active mod, I suspect the file could stay live for years.

You can try decompiling the script, and see if that has changed from what I posted above, seems unlikely though. What's in your Override folder in the way of UTCs?

You'll want to open those two MOD files with ERFEdit and extract k_psta_spawnha.ncs from sta_m45aa.mod and sta45b_trooper.utc, sta45b_troope001.utc, and k_sta_sithtrpenc.utc from sta_m45ab.mod. Check the UTCs first, see what appearance they point to.

To start with, temporarily take appearance.2da out of the Override folder and see if anything changes. Also check the Modules folder for sta_m45aa.mod and sta_m45ab.mod.

Can't see any UTCs for troopers in the 1st level module, just Sith and droids. Could be spawned via a script maybe. Edit: k_psta_spawnha seems to be spawning enemies from the 2nd level module (which is interesting, I didn't know you could do that): void main() { int int1 = GetGlobalBoolean("K_STA_SPAWNER"); int nGlobal = GetGlobalNumber("K_STA_HORDE"); object oNPC = GetPartyMemberByIndex(0); int int5 = (Random(10) + 1); string string1; if ((int5 == 1)) { string1 = "sta45b_trooper"; } else { if (((int5 == 2) || (int5 == 3))) { string1 = "sta45b_troope001"; } else { if (((int5 == 4) || (int5 == 5))) { string1 = "k_sta_sithtrpenc"; } else { if ((int5 == 6)) { string1 = "sta45b_appren001"; } else { if (((int5 == 7) || (int5 == 8))) { string1 = "sta45b_appren002"; } else { string1 = "sta45b_apprentic"; } } } } } But looking at those UTCs, they reference the Sith Trooper appearances. Are you sure you're not seeing some appearance.2da edit/conflict there?

If you are using a previous save in those locations, his default appearance will be stored in the save. UTC edits only work when entering an area for the first time. That is one advantage 2DA edits have - they will work regardless (assuming the row reference remains the same).

Another thing I never knew. Probably in both cases because I was too busy looting his corpse for the pearl. The 3rd UTC would appear to be kas22_xkomad_01.utc in the Czerka Landing Port (kas_m22aa).

Hah, never even noticed. PMBG or PMBH, depending on what armour you want. That will just use the first texture variant though unless you also change the racetex value, so editing the UTCs I listed above may be the simpler route if you only know the item name.

Typically you would edit the character's UTC/s for this, changing their equipped items. In this instance tat17_03komad_01.utc in the Hunting Lodge module (tat_m17ad) and tat18_11komad_01.utc in the Eastern Dune Sea (tat_m18ac) module. However, Komad has a unique appearance.2da entry (for some reason), row 445, so alternatively you could just change the race body model there.

A problem with vert ID perhaps? Are they changing when recalculating smoothing? MDLEdit says that the head mesh has 501 verts/749 tris in the binary model, but Max says the ASCII model has 502 verts/750 tris.

I'm not planning on adding any more heads. I had originally intended to use the Republic droid head for B4-D4. I still may, nothing is finalised yet. As to that collar thing, god no, that thing looks retarded. I'll probably move on to something else like the war and assassin droids for a while now.

In-game test: It may be a tad too shiny (although I am still using the vanilla CM_Baremetal, haven't tried it with other envmaps yet.). Also I think the normal intensity of the damage needs to be toned down a bit, at least on the head. And the colour is still a bit anaemic looking.

Now that they have finally broken cover, I can say very special thanks to bead-v for KOTORmax and MDLedit, without which getting these models into the game would not be possible, and ndix UR for TGA2TPC, which allows for the creation of functional tangent space normal maps. ================================== Got the classic style head mostly done, just need to add the neck and tweak a few things: Edit: OK, I think that's about it. On to unwrapping, creating the high poly, and texturing.

You'll occasionally see something like this: in the padding before the start of an animation sequence. Although it has been drastically reduced in the release version, to the point where I had to hunt around a bit to find an example.