DarthParametric

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.

Oh god dammit.... Thanks for pointing that out. Fixed.

View File Control Panel For Kashyyyk Shadowlands Forcefield This mod makes some minor changes to the forcefield in the Upper Shadowlands on Kashyyyk that gates access to the Lower Shadowlands. In the vanilla game, the forcefield is never actually disabled. Rather, the sound effect is simply turned off while the camera is pointed away from the forcefield, followed by an immediate area transition. It appears that Bioware did this due to issues with opening and closing doors via scripting. Additionally, there are no apparent controls for the forcefield, simply a frame and the field itself. The level model containing the forcefield has been edited to add a computer panel, fix a gap above the forcefield via some adjustments to the frame geometry, move some vines out of camera shot during dialogue, and prevent grass planes from spawning too close to the ramp and clipping through. The dialogue that occurs when interacting with the field has had some scripts injected to play animations implying that the forcefield is being switched off via the control panel. Jolee will now approach the control panel when the dialogue starts, and will face it when disabling the field. The field itself is now shown shutting down before the party transitions to the Lower Shadowlands. Additionally, there appears to have been an error in leaving out a script on one of the nodes that would stop Jolee from saying "You aren't going to ask about it?" even if you had actually asked about it, which has been fixed. Compatibility: The K1 Community Patch edits the Upper Shadowlands OnEnter script. Those changes are also incorporated into this mod. If you are using a mod that forcibly overwrites MOD files (like NPC Overhaul), make sure you install that mod first. This mod will patch a pre-existing kas_m24aa.mod in the Modules folder. Not compatible with any other mod that replaces the same level model (m24aa_09a). Not compatible with any other mod that puts kas24_force_01.dlg in the Override folder (although such a case should be fixable with a compatibility patch). Known Issues: In order to get the forcefield to close and function properly again after a level transition, it was necessary to resort to a hack function Bioware implemented for (presumably) the same issue they had with doors on the Yavin space station. In testing this has worked perfectly fine, however, the specifics of the hack are undocumented, so there may be edge cases I haven't encountered. If anyone experiences any issues with it, let me know. As you can see in the video, there's a subtitle error for one of Jolee's lines. Fixing it is better left to dedicated dialog.tlk overhaul. The mod doesn't touch the Lower Shadowlands module, so there's no active field or control panel on that side. Perhaps that could be an optional extra added in a future update. Acknowledgements: Thanks to @A Future Pilot for permission to distribute a modified version of K1CP's k_pkas24aa_enter.ncs Thanks to @JCarter426 for various scripting advice and troubleshooting, past and present Thanks to @LiliArch for correctly guessing that it wasn't just Bioware being lazy, which lead me to find Bioware's hack Thanks to @bead-v for MDLEdit and KOTORMax Thanks to @ndix UR for TGA2TPC The control panel textures include a mishmash of various textures from The Old Republic MMO The robes worn in the screenshots/video are from @JCarter426's Fashion Line I: Cloaked Jedi Robes for K1 Thanks to @ebmar for pointing out the lack of TSLPatcher.exe in the initial release Submitter DarthParametric Submitted 01/08/2019 Category Mods K1R Compatible Yes  

It is k_hbas_dialog.dlg in BIFs -> templates.bif -> Dialog.

Isn't that just a fade to black in the vanilla game? I thought the kiss was a mod. Edit: Yeah, here's the scene There's a mod that adds in a different animation for Bastila and the PC (ANIMATION_LOOPING_TALK_PLEADING it would seem) and changes the camera angle in order to fake the kiss.