DarthParametric

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.

In practice the only real difference is adding any appropriate MODs that M4-78 is missing to be installed to the Modules folder. The rest of the setup should be identical. It's mostly adding extra instructions to the readme. Although that said, M4-78 does use a different Korriban Academy module, so that is something to take into account. If you are overhauling the Overhauls, I'd say the more pertinent issue is switching to module injection rather than module overwriting, as it currently is (at least for the K1 version anyway, can't remember what the TSL version does). That causes problems regardless of what version the game is.

There's no functional difference in the creation of changes.ini, and there are zero special requirements for K1 beyond the user locating the install directory (<Steam/Library>\steamapps\common\swkotor). For TSL, the default is the same aside from the directory (<Steam/Library>\steamapps\common\Knights of the Old Republic II), but the real issue is that you need to account for people using Workshop mods. Generally, you should advise your users to avoid using any, if possible, and ideally only TSLRCM/M4-78 if they must (and with the "Civil War" now over, any need for that is arguably past). However, people will use the Workshop regardless, so you'll want the version of TSLPatcher that Fair Strides patched to ignore the dialog.tlk requirement of stoffe's original version/s. Additionally, you'll need to instruct your users to install into either the TSLRCM Workshop folder, or the M4-78 Workshop folder if they are using that. There's also now a combined mod of the two. You'll want to ping @zbyl2 and ask for permission to include TSLRCM's MOD/RIM files, as you'll need to install those for an M4-78 Workshop-based install. Basically the Workshop system for TSL works on a straight install order priority system. Any duplicate files will default to the version in the most recently installed mod. So if a user installs TSLRCM from the Workshop, then installs a player head mod from the Workshop, they will break the game because the head mod's 2DAs will be used instead of TSLRCM's. People get around this by using TSLRCM's (or probably M4-78's) 2DAs as a basis, but that means you can only install a single such mod, as any further mods would break that previous mod. It's a mess, hence why you should push for people not to use it. Workshop directories: TSLRCM (English) - <Steam/Library>\steamapps\workshop\content\208580\485537937 M4-78 (English) - <Steam/Library>\steamapps\workshop\content\208580\485560877 Combined TSLRCM + M478 (English) - <Steam/Library>\steamapps\workshop\content\208580\1402798020

That is a separate mod. Did you read the description and download the normal map fix for that issue? Yeah that's bad. I'm guessing your game is installed somewhere in Program Files. At the very least you need to run TSLPatcher as an administrator in that case. As the readme clearly states: "You may get warning messages regarding certain module (.MOD and .RIM) files already existing. This is normal and no cause for alarm. The files are only included for Steam Workshop compatibility reasons".

Good point. It's a v5.0 archive.

It downloads and opens fine. The problem is on your end. I'd suggest changing the filename when the Save As dialogue pops up. The characters may be be causing trouble. Otherwise try a different browser.

Ah, that is a skin weight issue then presumably. Probably either not enough or too many neck weights on a few verts. I'll have a look at it and see if I can spot it. Edit: Here's the problem. Two verts on either side have neck weights they shouldn't. I've updated the archive above. Redownload it and see if it is an improvement.

It looks like a couple of cheek verts on each side are inset a bit too far. It may need some further tweaking, but try this and see if it is an improvement: https://www.darthparametric.com/files/kotor/k1/[K1]_Player_Head_PMHC01_Cheek_Adjustment.7z

My 2c: Just have simple separate Mod of the Year awards for K1 and TSL and nix the individual categories.

Nothing has changed regarding creating 3D models. You'd have to create your example in Max/GMax (or Blender), just as you have always had to, and will continue to have to do in the future. The new/improved compilers are just that - compilers. Their function is solely to create correctly formatted binary models.

That hasn't been necessary for over a year now. Both MDLEdit and MDLOps v1.0 will allow you to recompile edited level models with no issues, for the most part. For changing textures, MDLEdit will let you change the texture names directly in the editor itself (at the least the more recent beta versions anyway).