DarthParametric

I was still in the transitional phase back then, moonlighting here while riding out the final days of LucasForums. In hindsight, yeah, probably should have released it here (and the HK mods), but I'm not big on hosting a file in multiple places, and I don't like pulling something from a site once it has been uploaded.

As I said in a previous post, this approach is only for patching files in the MOD, not inserting files. The current version of TSLPatcher can't handle that. If you are only changing or adding entries to existing files, you shouldn't need a copy in the tslpatchdata folder anyway. That's only for new files, or ones that have deleted nodes and thus need to outright replace the originals. In those cases you'll want to revert to the usual approach.

An ERF is an archive (the same as RIMs and MODs). The DLG files are inside it. Extract the DLG you need via KOTOR Tool.

Yep, looks correct. Using the module name is a nice touch - helps keep things organised. I'll probably steal that idea the next time I need a setup like that.

It's on the backburner for the moment while I deal with other things. I'll get back to it at some point.

With the mask is probably a package deal if you want the hood, as it would need to be a disguise for that work. Otherwise it's both sans mask and hood.

I can see six door hooks in the module. Three of them would appear to be the sewer entrances (one of which, door_07, is listed as static in the GIT), then one for the gate to the infected compound in the village (door_05), and two for the elevator (door_04 outer, door_09 inner, which is static). I can't see one for the village main gate however, yet that has an entry in the GIT. The north door hook is door_08, but that has no entry in the GIT. If you look in the module's RIM, there are seven door UTDs. One is unused in the GIT, however this is a static door. So it seems to me that you'd need to add a new UTD that duplicates sw_door_taris004.utd with a new ResRef and Tag (you could presumably repurpose sw_door_taris005.utd for this, since it appears unused). You'd then have to duplicate the GIT entry for the south door, which points to TemplateResRef sw_door_taris004, and change the co-ords to that of the door_08 hook, and point it to your new UTD. This would require a save before entering the module for the first time. This is probably something that can be added to the K1 Community Patch in the next update. Edit: I just realised there is a transition zone in front on the north entrance, so even if you add a door you can't actually get close enough to open it before being transitioned to the next level. So that would need adjusting as well. Edit 2: So on further inspection I discovered that even with the transition cleared, the walkmesh is also blocking access to the doorway, so that needs editing as well. I've put it all together if you want to try it out. Put the MOD in the Modules folder and the WOK in the Override folder. It will require a save before entering the Undercity for the first time. https://www.darthparametric.com/files/kotor/k1/[K1]_Taris_Undercity_Sewer_Access_North_Door.7z

What's the specific location? Do you have a screenshot of the map? What is required to add a door depends on whether the module is already set up to have one there, or whether a hook needs to be added.

If you are getting errors, you didn't change all of the instances of the Base name. Seeing as MDLEdit does actually allow you to edit the Base name, as @ebmar pointed out above (contrary to what I thought), then I would suggest you stick with using that. You're probably less likely to get yourself in trouble.

There are plenty of threads on the Steam forums detailing the issues. If any intrepid soul wants to start collating such a list, this is probably a good place to start.

Correct. The filename must match the Odyssey/AuroraBase name. Changing the filename alone is insufficient and will potentially lead to problems. The old way used to be hex editing to change the names of both the Base and any textures. It may still be desirable to go that route due to issues both MDLEdit and MDLOps have with generating incorrect smoothing data. There are few free hex editors around, like HxD or Frhed for Windows, although it's not exactly a user-friendly approach. Your other option is to decompile to an ASCII with either MDLEdit or MDLOps, edit in a text editor, then recompile back into a binary. While MDLEdit will let you edit texture names directly in the editor, it doesn't offer Base renaming, so editing the ASCII is your only option. Once you have a custom head with a custom texture, you can add it to heads.2da, You will also need a new entry in appearance.2da that points to the head ID. You can edit the appropriate UTC to point to your new appearance.2da row ID.

Yeah envmaps are one of a long list of things Aspyr broke in the Steam version.

That could be something leftover from NWMax.

Your only option with GMax is doing it via scripting. I had a quick look around but couldn't see anything. I know that the Dragon Age Origins I/O script had some sort of function that could replicate the World Units thing, although I am unsure if it worked in the GMax version. It's probably the sort of thing that would be nice for @bead-v to add to KMax, if he ever returns from the Unknown Regions.

There's no reason to screw with the vanilla names, and doing so will break things if you don't properly propagate the changes. "If it ain't broke, don't fix it".

The Czerka office reuses the Swoop interior. It's done a couple of times throughout the game. If you are modding either you'll need to make proper use of MODs, not just dumping stuff in the Override.

The mouthbox is the interior of the mouth, the bag of polys inside the head (you can see it in the side shot in the 3rd pic I posted above). Unless you are a dentist, I doubt you got a good look. No. KMax reads and assigns smoothing groups based on what is in the ASCII, and will export the same if you don't change it yourself. Max/GMax has an automatic function to do this based on angle, which you can adjust, but the problem is imported meshes will always be split along UV seams, which the automated smoothing typically takes as a hard edge and thus splits smoothing groups between. If you are using GMax, you'd probably need to manually assign the smoothing groups, as it lacks some of the tricks I would use in Max. Basically you'd go into the Element submode of the Editable Mesh and pick all the elements that should share a smoothing group, and set them to the same number in the Smoothing Groups section under Surface Properties. Smoothing is probably something you want to watch a video tutorial on, as it is hard to convey it in text. The only problem is GMax is so ancient now I don't know if there is such a thing. You can try watching some Max tutorials, but there may be parts that don't apply to GMax.

That's a smoothing issue. It should be unrelated to you renaming the bones. If you simply decompile and recompile the vanilla binary you should get the same result. The problem is caused by the smoothing groups being incorrectly assigned/calculated during decompiling. The mouthbox needs to be set as its own smoothing group, or a different smoothing group to the face at any rate, otherwise you get shading errors at the mouth corners. Here are the smoothing groups I got from a decompile: This is not something you can fix in a text editor. It needs to be done in a 3D app. It may need additional tweaking, but try this and see how it looks: https://www.darthparametric.com/files/kotor/k1/[K1]_Head_Commoner_comm_a_m.7z

If you want to explore the option, grab the TSLPatcher.exe from my Fixed Holograms mod and have a look at how the changes.ini is set up. It allows for a unique reference for each file in the GFF list, with the ability to specify the proper filename in the actual changes list. For example: Although it should be noted this approach only deals with patching existing files. Anything that requires physical files with duplicate filenames to be included in the tslpatchdata folder will obviously still be subject to the separate install routine.

The multiple install issue is due to duplicate filenames? If so, there is a workaround to that via a specially patched version of TSLPatcher Fair Strides whipped up.