DarthParametric

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.

The screwiness between animations still persists. You may want to add that to a "known issues" section in the download description so people are aware of it.

Nice work. I liked the nice specular highlight you managed on the stone floor on the bottom level. The collision on the rotunda seems like it could do with being reduced a bit maybe. It might be worth considering some sort of physical barrier like velvet ropes - I've always hated invisible walls around what should be navigable terrain. I'm curious about those assassin droids. Do they ever engage in combat, or are they just for flavour? I'm wondering whether something more unique might be in order. Collision shouldn't be an issue with the new model tools. It should function like the vanilla models.

I just tried a decompile of a vanilla saber, import/export into KOTORmax, recompile and get the same thing. Trying to decompile the new binary gives an error: Here are the files: https://www.darthparametric.com/files/kotor/misc/Recompiled_TSL_Saber.7z