Leaderboard

Holocron Toolset supports directly reading from and writing to files stored in ERF/RIMs, so a middleman shouldn't be necessary. But there is a ERFEdit-like tool included with the toolset should you go that route or need to create a blank ERF file.

UTI is for Items [weapons, armors etc.], UTC is for Creatures [NPCs, etc.]. No, make it a habit to put back module-specific templates back to their own MODs/modules, such that one you mentioned above. You can use ERFEdit as the external-tool to work on it. As with Holocron Toolset @Cortisol might have better answer as I haven't tried the feature yet.

Luckily we rarely have to overwrite files when modding the Knights of the Old Republic games. Instead we can used edited copies of the original, vanilla files that will then be prioritized over the original game assets. However that also means that one file can be present in multiple locations at once, making is necessary to know which file takes precedence. That's where this tutorial comes in. I'll try to give an overview of the different ways different file types are prioritized. Let's start with an overview of the places a file could be in: Overview of file locations The original game assets: These are stored in multiple packages across the entire game installation, ususally coming packed in .rim, .bif or .erf files. I don't know the priorities between those but since you shouldn't edit them anyway, it doesn't really matter anyway. The Override folder: This folder located in the main installation directory is where most of your modded files will go. The Modules folder: This folder has all the module files (.rim) by default. There are two .rim files per module, named the same except for the ending "_s" on one of them. These are where the game stores assets for that specific module. Again, you won't edit these, but this folder is also where .mod files go. These are basically copies of the .rim files, packing the contents of both .rim files of one module into one file. Sometimes it is necessary to put files here due to the way the game prioritizes files. But they are also important when two files of the same name are used in different modules and you only want to edit one of them. Instead of putting your edited file in the Override where it would override both occurences, you'd put it into the .mod for the module you want the edit to be used in. Savegames: Some information is also stored directly in the savegame. You'll usually not edit this information, but knowing that it's there can be important. You'll see why in a bit. Those are the main locations for files, with the second and third being where you'll ususally put your files. So now let's get to the priorities. The game will always start at the highest priority and if it can't find the file it'll continue with the next step until it finds the file. The usual case This usual case holds for most of the game assets, including textures (.tga), texture information (.txi), models (.mdl and .mdx), scripts (.ncs), dialog (.dlg), GUI files (.gui), 2da files (.2da) and many many more. Those are prioritized in the following way: Override folder .mod files in the Modules folder vanilla assets Unless you have a file that's different accros two or more modules, you can safely put these files into the Override folder. .ut* files .ut* files (i.e. characters (.utc), items (.uti), triggers (.utt) etc.) are different due to the fact that their information is also stored in the savegame the first time they're accessed in a playthrough. The priority goes as follows: Savegame Override folder .mod files in the Modules folder vanilla assets The important difference here is that the information in a savegame takes precedence over every other option. This is why you always have to load a savegame where the module you're working in hasn't been visited yet to see your changes. For your final mod you'll still place the files in the Override with the same exceptions as described above and you should note that a fresh playthrough or a savegame from before visiting a certain area is necessary for the mod to work in the description. Static Area Info .are Static Area Info files (.are) behave the same as .ut* files: Savegame Override folder .mod files in the Modules folder vanilla assets Dynamic Area Info .git Dynamic Area Info files (.git) behave slightly different when compared to the prievous file types. This difference is quite important though, and you'll see why: Override folder Savegame .mod files in the Modules folder vanilla assets As you can see the Override folder takes precedence over the information stored in savegames. This will result in an area being reset everytime the player loads a savegame or re-enters that area while the corresponding .git is in the Override. Thus you should NEVER have a .git in the Override for a final mod. This behaviour can be quite useful for testing though. Just make sure to put the .git in the .mod for the final release. Module Info .ifo To be honest, I don't know what module info files (.ifo) do and I don't think I've ever seen a mod that edited those, but I want to mention them anyway. Since this file is named the same for every module (module.ifo), you really don't want to place it in the Override but keep it in the .mod should you ever need to edit it. Edit: According to DarthTyren, all the module.ifo file does is to tell them game which .are and .git file to use for a module. So you probably won't edit it anyway, but should you require to do so at some point, follow the recommendation above. dialog.tlk This very important file, cannot be overriden by a different version in the Override folder or somewhere else. Instead the file has to stay where it is (main installation directory) and must be modified directly. Override subfolders In K1 all files have to be placed directly into the Override folder and files in subfolders won't be recognized by the game. In TSL this has changed and you can put your files in subfolders. The priorities then goes as follows: Main Override folder Subfolders in alphabetic order with numbers preceding letters Sub-subfolders won't work in TSL either and you should always keep in mind that putting a file in a subfolder will make it harder to detect incompabilites as no files will be overwritten when installing a second mod using the same file in a different or no subfolder at all. Most of you probably knew all of this already but I've been looking into it recently and figured I'd share it for those that are new to KotOR modding. May it help you in your career