DarthParametric

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).

This was expressly noted:

I don't use them myself, as a general rule, but I believe this should be what you need for K1 - https://www.nexusmods.com/kotor/mods/1076

As detailed above: There will only be an existing MOD file if you have one from another mod. That's why they are used, so as not to overwrite the vanilla game files.

It won't work for players without creating a disguise item. I have no plans or interest in making one.

The is only a single GIT per module. As I said above, make a copy of the GIT somewhere and then edit it with K-GFF. You no longer need KTool after having extracted the RIMs. Have a look at the archive I linked to at the end of the summary.

You extract the entirety of both RIMs. Don't expand them or select any of the contents, just click on the top level and use the button noted above.

This is a brief overview. I would suggest starting by creating a folder to hold all your working files, with sub-folders as appropriate (here's an example) Extract both the RIM files for the module in KTool under RIMs -> Modules. Select unk_m41aa.rim and unk_m41aa_s.rim in turn and hit the "Extract Entire RIM File" button on the top right (I put them in the SOURCE folder in the above example) Using the ERF/RIM Editor, create a new MOD file named unk_m41aa.mod Select all the module's files you extracted in KTool, and drag them into the ERFEdit window, then save the MOD Make a copy of the module's GIT file, m41aa.git Open the GIT with K-GFF Start by going to View -> Fold All, then expand the base STRUCT node to reveal the GIT's structure Expand the CreatureList node If you expand the first few STRUCTS, you'll see there are already three Gizka in this module using two ResRefs - unk41_gizka and unk41_gizka002 Checking those UTCs in KTool, we can see some important dev notes in the Comments tab, so we'll go with unk41_gizka In K-GFF, right click on the first STRUCT and choose Copy STRUCT and then right click on the base CreatureList node, right click, and choose Paste STRUCT A duplicate of that STRUCT will appear at the bottom of the list, which we can now edit as appropriate Before proceeding further, you'll need some co-ordinates. You can generate these either via loading up the module layout in Max/GMax or by running around in-game with an armband that spits out co-ords of the player's position. Edit your new entry in the GIT, changing the X/Y/ZPosition values as appropriate You will see two values for rotation, XOrientation and YOrientation. These are the COS and SIN of the rotation in degrees, respectively. As these Gizka will be hopping around anyway, just leave the existing values. Repeat with duplicating and editing the STRUCT for however many new Gizka you want to add. Save the GIT when done. For testing purposes, you can just copy the MOD into your K1 modules folder, then open it with ERFEdit and drag and drop your edited GIT in. Save the MOD. Start the game and load a save from before entering the Central Beach module for the first time. Examine the quality of your handiwork. You'll probably want to test various position tweaks. They take a little bit to start hopping, so probably don't put them right outside the Hawk's loading ramp. Once you are happy, you can set up the mod with a TSLPatcher installer Read the included PDF for instructions on how to create a TSLPatcher setup The gist in this instance is you need to difference your edited GIT against the original and have it inject those changes into the MOD Here's a basic setup so you can see how it works

The specifics can vary depending on what exactly you want to do, but as a general rule you typically define what creatures are in a module via the module's GIT. This dictates exactly how many instances of a given UTC are in the module (each creature doesn't necessarily need a unique UTC, you can spawn any number of duplicates) and where they are positioned. Alternatively, some situations may instead call for the creature/s to be spawned via script. This is typically the case for cutscenes or quests, where you only want the creature/s to appear under specific circumstances. In the case of your Gizka example, assuming you want them to be neutral (i.e. non-combat) background creatures, adding them to the GIT would be the way to go. For that you could just reference the pre-existing generic c_gizka.utc without needing to add a custom UTC of your own. All you'd need to do is figure out how many you want and where to position them, then add that info to the module's GIT and inject it into a MOD (that should be Central Beach I believe - UNK_M41AA). If you wanted to get more fancy and make them interactable, you could look at the Yavin station and Ebon Hawk modules to see how they handled being able to kill them.