DarthParametric

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.

Not at this juncture, no. This thread is primarily for experiments I do from time to time, not necessarily anything I am committed to releasing.

Speaking of which, that's actually one thing the armbands are really good for - positioning when right up against collision. Since characters have a "personal space" boundary around them, it can sometimes be difficult to gauge exactly where they can move in close proximity to collision when working in Max, etc. I found this when doing some adjustments for the post-Lehon crash cutscene in K1. For one shot where I had Mission walk to a console, she wouldn't obey using a target co-ord taken from Max, because she couldn't actually reach it, even though it seemed to me like she had heaps of room. So I hopped into the game and jammed the player as far as they could get into that corner. Using the armband's position resulted in Mission correctly doing what she was told because the waypoint was now a few centimeters further back on walkable geometry.

Armbands are more "approximate" than accurate. Typically though the quaternions they output should be more or less in the right direction. Or at least that's my recollection from the odd occasion I've used either StarAdmiral's "Utility Armbands" in K1 or Darth333's "WhereAmI Armband" in TSL. If you want truly precise values, you'll have to derive them by loading the module into Max/GMax/Blender.

That does mean it probably won't work on Linux/Mac, since they are case-sensitive OSs. Although the actual filenames are all lowercase aren't they? So that should be fine in that case. Also, as to ones not matching, yeah, a lot of the unique/quest-related items don't use matching Tags/ResRefs. Maybe your next coding project can be to browse every UTI in both games and compile a database of mismatches.

There is no function to get the ResRef. The game doesn't store that value. That's why vanilla items typically use the same value for both Tag and ResRef, so yes, using GetTag is the right function. Unless he is wearing an item from a mod, in which case all bets are off.

You need to switch them to the K1 rig. There are subtle differences between the rigs of the two games, which causes the facial problems.

Well I was thinking still using planes, but maybe just some better ones. But it still would probably look extremely fake even if the textures themselves were high quality given how close to the player the planes are.

Does Terragen have the ability to create trees? Something that I've always hated is those terrible planes that border the edges of the Dxun map.

Everyone has to start somewhere, and TSLPatcher is kind of opaque in how/why it does certain things. The best advice I can give you is to look at existing mods. Chances are whatever you want to do, someone has done something similar at least once in the last 15 years. Find that mod and poke through its innards to see how it was put together. Although you do need to be careful with older mods, since there were some bad practices in the early days, like putting pre-edited 2DAs in the Override instead of dynamically editing them, one of the primary tasks TSLPatcher exists for.

Here you go. changes.ini So, some explanations for the changes. You didn't add the module (MOD) file to the install list. You always want to make sure this is set to copy, NOT replace (it will say "File" if in changes.ini if it is set to copy). That way it will only copy it there if it does not already exist. Since most people will have TSLRCM installed, and that adds MODs for almost every module in the game, you don't want to overwriting them. Or ones added by other mods, more so in K1. Most of the files intended for the Override, textures and new UTIs, got added to the GFF list. As the name suggests, the GFF list is for GFFs (e.g. UTPs, UTCs, GITs, etc.), but only for ones you are actively editing. This is sometimes a new one you are editing, especially in the case of UTCs where you may need to dynamically change an appearance.2da reference, but in your case you needed to add these to the file list. I have set them to replace, mostly so you can see how that works. For your own unique files this is typically fine, and may sometimes be a requirement for a patch/update to an existing mod or the like. But in some instances copy may be the more desirable approach. You did not set the target destination for the actual GFF that was correctly in the list (g_tresmillow007.utp). This is critical (and the entire point of this TSLPatcher setup) because if you don't specify a target then it defaults to the Override. Which is the same problem you had originally. The destination has now been set to the MOD added above (I have assumed 152HAR is the intended module, so change if necessary). It should be noted that for a file in the GFF list that already exists in the target location, such as in this case, you don't need to include a physical copy of the file in the mod, since everything TSLPatcher needs is in the ini. However, if you are adding a completely new file then you do have to include a copy. More of a minor issue, but you had it set to automatically look up the game install location, which is the default setting. You should always set it to user defined, since TSLPatcher only knows about the CD version. Typically in modern use (with GOG or Steam versions of the game) it just fails to find the install and asks the user, but in certain edge cases this can cause problems. You can change this in the Settings section up the top, but you have to manually hit the Save Settings button for anything in there (unlike changes made in any other section, which update automatically). As a final note, you should take a look at changes.ini so you can get a better understanding of what the program is doing. There are some things that are just easier to change in the ini file directly (and at least one thing that is only possible to change there), so checking it after every edit is a good practice to get into.

Also doesn't work if you edit an ASCII?

You need to post the changes.ini it produces to properly see what is actually going on. But in a word, no. Most of what you have there is incorrectly under GFF.

The rules were recently changed to allow ports between K1 and TSL. If you are porting vanilla heads, that's fine, but the rules still forbid porting other people's mods without express permission.

Template refers to UTx - UTI, UTC, etc. That's what the T stands for, Template.

There's no reason you need to switch if you'd prefer to use a container, you just need to do it properly. And in TSL especially, as you've discovered, all you've really done is exchange that problem for a different flavour of the same problem. Obsidian was extremely lazy with their design and reused a lot of Tags/ResRefs across multiple modules. This means you can't just dump stuff in the Override folder, you need to learn how to use TSLPatcher and do module injection. For either case, module injection should solve your issue, since you'll only be adding it to that specific instance of an inventory. Whichever one you prefer, the basic operation is the same. Extract a copy of the original template. Make a duplicate of that and edit it with your changes. Use TSLPatcher's ChangeEdit to create a new changes.ini and difference your edited file and the original to generate a list of required changes, making sure to specify the destination module it needs to go to. If you have additional items that need to be added, like custom UTIs, these can also be added, either to the module or the Override as necessary. Then you need to extract the vanilla module files from the two RIM files (and in TSL also the associated xxx_dlg.erf) and bundle them into a MOD using ERFEdit, and in ChangeEdit set this up to be added to the Modules directory (importantly, not set to overwrite). You should read the PDF that comes with TSLPatcher as well as browsing through the tutorial sub-forum for further information.

Just so you know, Odyssey's normal map implementation is piss weak. There's generally little reason to bother with using them in KOTOR. You won't get the sort of results you'd expect from pretty much any other engine from the last two decades. In my experience, the only time you get any really noticeable result is when used in combination with a cubemap mixed at 100%. Which is probably fine if you are making a Terminator total conversion and need a lot of chrome, but otherwise a waste of time.

https://deadlystream.com/topic/5735-mdledit-bug-reporting-thread/?do=findComment&comment=73932

Are you kidding me? It will be stretching on for months. I doubt he's even off Peragus yet.

1.0.104 should be the current beta version.