DarthParametric

Your setup is completely broken. The UTP shows it has been edited by KTool but lacks both local or TLK strings. Whatever it is you are doing, you're doing it wrong.

The issue happened for me when the conversation triggered without the player being jumped into position. If you want to try reproducing it again, you could try hammering on the left mouse button during the end of the montage. It's possible the script that jumps the player got skipped.

Hrm. Where was the player located when you reloaded?

Yes, other mods can cause problems, especially if you are using the Steam Workshop.

Not sure if you already have it, but I just noticed this while looking for a locked door barkstring: <string id="20037" sound="nm26acdoor28004_" soundlength="0.000000">[This door has been permenantly sealed.]</string> <string id="20342" sound="nm27aadoor01000_" soundlength="0.000000">[This door has been permanently sealed.]</string> 20037 is spelled incorrectly.

You have no dialog.tlk in the game's root folder? Running without it is essentially impossible, since it contains all the text in the game. By "data" folder I assume you mean the Override folder? Or the actual Data folder?

Attach the new MODs again, and the TLK/s as well.

What happened after you saved/reloaded? It proceeded normally on the subsequent attempt?

If you are using that mod then all you should need to do is simply set her Dantooine equipped outfit to a Jedi robe, since JC's mod will have set her default appearance to use robes. Note though that she will also need the Jedi Defense feat, since that is a prerequisite for wearing robes (and her UTC doesn't have it by default). This one should be ready to go if you drop it in your Override (although note it won't work with a save where you have already encountered her in the Courtyard, you'll need a save before she has spawned). dan13_yuthura.utc

By default, Yuthura's appearance.2da row forces her to always wear the Sith uniform, regardless of what clothing/armour/robes she has equipped. Since you only want to change her on Dantooine, and since some other mods change her appearance row so that she wears Dark Jedi robes on Korriban, the best approach would be to create a new custom row for her in appearance.2da and set her UTC on Dantooine to use that appearance instead of her vanilla one.

I had it during development when the player wasn't correctly jumped into position post-montage, but that shouldn't be present in any public build (and I haven't seen anyone else report it). I assume you aren't using any other mods that may edit that scene and its related scripts?

It's entity count that it really chokes on, so static meshes shouldn't burden it too much. What you'd want to do though would be to combine as many of them into single meshes as possible (you'd need to do that per-room though, so they can be dropped out by the VIS separately).

These MODs still have your original changes. I said in my post above that you needed to revert them before installing again with the modified ini. Use these and try again. Modules.7z

It should be. That's one of the older fixes from previous versions. No, as per vanilla. K1CP does not change this. Use a standalone mode like JC's Back in Black. Not random, one of the applicants. You could just never see him properly before because of the terrible way the NPCs were positioned. Presumably he dies as soon as he gets into the Valley. I'd have to check, but my memory of that is it was moved from somewhere else, and is once again from an earlier version of K1CP (so blame @A Future Pilot).

Stop using KTool for starters. I swear it creates far more problems than it solves. Use it as a can opener only and you'll have a better time. For script compiling, just call nwnnsscomp directly. Here is a batch script that may be of use: Batch compile NSS Note that each game needs its own version of nwscript.nss, so in practice you'll likely want to have two separate versions that each get called by separate game-specific batch files. Yeah, you've summed it up pretty much. You'll note that vanilla scripts always use waypoints, and it seems like there are some subtle reasons for why this is the case. Functionally though there is no real difference, aside from the specific functions you use. One trap for young players though is that an NPC will never get closer than about 1m to a waypoint, even if you set the optional distance value lower. So you may need to offset your waypoints to account for this if you require a high degree of accuracy. This doesn't apply to locations. A DLG has to be set to either human or computer in the root node. So when you need to switch from one to the other you'll have use a script to assign an ActionStartConversation to the appropriate NPC or object. You can specify a DLG directly in the function, so it doesn't need to be attached to the owning object's template. What you want to do with that is modify the door's template and set it to require a key. That way it will not get a security interaction popup and can only be opened via script. There is nothing special required on the script side. Just the usual AssignCommand(oDoor, ActionUnlockObject(oDoor)); and AssignCommand(oDoor, ActionOpenDoor(oDoor)); If you lock it again afterwards, there will be no way for the PC to open it. Typically you'll want to attach an OnFailToOpen script and have it fire a BarkString about the door being sealed or whatever. There are a number of vanilla examples.

Attach the two modified MOD files from your Modules folder.

You should collapse the Unwrap UVW modifier into the Editable Mesh modifier before exporting by right clicking on it and choosing "Collapse To". This will only collapse everything from the selected modifier down, as opposed to "Collapse All" which will collapse the entire stack to the bottom modifier. It's a useful habit to get into when dealing with modifications to skinned meshes, where you definitely do not want to be collapsing the Skin modifier. That said, I think KMax does support parsing a floating Unwrap UVW modifier, and there are sometimes workflow benefits to keeping it as a separate modifier, but I prefer to collapse it for an export version. You can always save out a separate "working" version of the file with an uncollapsed stack if you want to have a backup. Tweaking a mesh after unwrapping it is fine - i.e. shuffling vert positions around. Adding new geometry is not recommended, since they won't have UVs and can screw up your existing layout.

Did you try it from a save before entering that module for the first time? It won't work if you load a save from already in there. Also, do you have the physical UTPs in your tslpatchdata folder?

This one adds it as a disguise, which is not the most ideal approach: https://www.gamefront.com/games/knights-of-the-old-republic/file/keep-bastila-s-slave-outfit If you want something simpler, Kex's tutorial breaks down what each column of appearance.2da does. What you want to do is edit Bastila's row (label "Party_NPC_Bastila") and replace one of the existing body columns with the slave outfit. If you wanted to make the slave outfit appear for her underwear, for example, then all you would need to do is edit the texture, since the slave outfit shares the same body model. The underwear appearance is body A, so you'd just need to edit the "texa" column which is the texture and change that to "P_BastilaBAS". If you wanted instead to change her clothing appearance, then you'd need to change both the model and the texture. Clothing is body B, so you'd change the "modelb" column to "P_BastilaBA" and the "texb" column to "P_BastilaBAS", same as before. You could do the same for any or all of the other body appearances as takes your fancy. C to H are armours, I is Jedi robes, J is Revan/Star Forge robes.

Textures aren't universal. You can't just rename a random texture and have it magically work with a different model. For the most part what you talking about in broad terms is done via an appearance.2da edit. That defines the models and textures for each given body type - underwear, clothes, armours, robes. If you want Bastila to wear her slave outfit (or alternative versions), there are already a bunch of existing mods for that (unsurprisingly). Aliens are primarily full body models - i.e. they don't have separate heads. So they are limited to some simple palette swaps unless you plan on making custom models. As to doing it yourself, yes, it's doable once you learn the robes. But not without tools. Like I said, it's not magic. Some simple filename changing is not going to achieve much (besides a mess).

Are you using a non-English version of TSL? You used KTool, and the first thing it does is break TLK references, turning them instead to local English strings. They won't show up if you are running in another language. Roll back using the backups TSLPatcher makes, then try using this config: changes.ini

You're not looking in the right place. There are a bunch of placeables, including some invisible ones used for the Force items. They do use an OnUsed script to give the items to the player though, k_mus_treasure: void main() { if (GetTag(OBJECT_SELF) == "mu_treasure1") { CreateItemOnObject("a_robe_21", GetFirstPC(), 1); } if (GetTag(OBJECT_SELF) == "mu_treasure2") { CreateItemOnObject("a_gloves_12", GetFirstPC(), 1); } if (GetTag(OBJECT_SELF) == "mu_treasure3") { CreateItemOnObject("u_l_crys_18", GetFirstPC(), 1); } if (GetTag(OBJECT_SELF) == "mu_treasure4") { CreateItemOnObject("u_l_colo_09", GetFirstPC(), 1); } SetGlobalNumber("506OND_MuseumThief", 1); DestroyObject(OBJECT_SELF); } So adding extra items is just a matter of editing the script and adding in some extra CreateItemOnObject instances for one or more of the placeables.

TSLPatcher only knows about the registry keys for the CD versions, so typically auto-lookup won't work for modern users, since they'll have the GOG or Steam versions. It's not advisable to use anyway, since it can cause problems in some cases with people that have multiple/old installs.

It should be fixed in K1CP, but it won't work with your existing save. You'd need a pre-Dantooine save, or preferably a completely new playthrough.