DarthParametric

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

No. That thing always looked like it was screaming to me, with its giant wide open "mouth". I never liked the design. I might do one more head in the style of the vanilla KOTOR protocol droid. Not sure yet. As I said earlier in the thread, it would be a simple appearance.2da and/or UTC edit. Nothing particularly arduous.

Any UTx file from templates.bif can go in the Override folder. Those are generic/universal. Anything specific to a module however may have to be bundled into a MOD, unless it has a unique filename. TSLPatcher is a necessity for any publicly released mod where conflicts may arise. For example, edits to 2DA files like appearance.2da. If you are just editing some basic UTx files then they should be fine loose.

Make sure you aren't confusing a MOD file with what some other games use. In KOTOR's case, this is a module file. It overrides the RIM files that contain the vanilla content for a given module. For example, if you wanted to create a MOD file for the Nar Shaddaa Landing Pad module, you'd combine the contents of 301NAR.rim and 301NAR_s.rim into 301NAR.mod, editing the appropriate files. This MOD file would then go into the game's Modules folder (not the Override folder). You use MOD files in cases where you want to edit or replace module-specific files that would cause conflicts if you just put loose files in the Override folder. For example, UTCs for generic mooks with the same filename might be used in multiple different modules, but have different content (different tags/resrefs, different scripts, different appearances, etc.). Content placed in the Override folder will override based purely on filename, so you can end up unintentionally replacing content in a whole raft of different modules, which can lead to all sorts of problems. This is particularly an issue with TSL, as Obsidian was fairly lazy with their filenames. Subsequently there are a lot of duplicates that will cause issues when being modified unless confined to a MOD. Of course the next issue you face is there may already be pre-existing MOD files from another mod. This is particularly the case for TSL, where TSLRCM has a MOD for just about every module. If you are planning on publicly releasing a mod that edits a pre-existing MOD file, you'll need to make use of TSLPatcher to inject your content to ensure compatibility.