Kexikus

I'm currently setting up the installer for my Full Jedi Council mod v2.0 and I've run into a problem. My mod edits holorec.dlg and since this file is also modified by several other mods (TSLRCM, TSLRCM No Overlay, PartySwap to name a few) I use TSLPatcher to apply my changes to a file already present in the Override. The problem is that TSLRCM places its edited holorec.dlg in 950COR.mod and not in the Override. So there are two options: Apply my changes to the holorec.dlg in 950COR.mod which could be either from TSLRCM or from the 950COR.mod that I install if it's not present. But then any of the other mods that places holorec.dlg in the Override would override my changes. The other option would be to make my changes to holorec.dlg in the Override. That way I could apply them to a holorec.dlg already installed there by other mods but that results in an issue when installing on a vanilla installation or with only TSLRCM. Then I'd have to provide a holorec.dlg that these changes could be applied to. So either I'd use the vanilla holorec.dlg for that, overriding TSLRCM's changes or the TSLRCM file, installing TSLRCM changes for a user who probably doesn't want them or he'd have installed TSLRCM before doing so. I could of course just put TSLRCM as a requirement in my read-me but I'd rather avoid that. Ideally I'd just tell TSLPatcher to modify the holorec.dlg in 950COR.mod and if holorec.dlg is present in the Override folder modify that as well. The first part is no problem but so far I've not been able to tell TSLPatcher to do the latter. Is this even possible? And if it is, how?

It's no different in KotOR 2: TSL and SLM doesn't change anything about that. As you probably know, you can change the color in your lightsaber by swapping the color crystal on a workbench both in K1 and in TSL. From the vanilla games, where every saber (of the same type, e.g. single blade sabers) has the same hilt, one might get the impression that this simply swaps the blade texture. However that's not the case. There is one model for each lightsaber type in each color and then there's a 2da file (2d array) called upcrystal.2da that assigns each color crystal the models to use for a standard, short or double saber with this crystal. That's why it's impossible to disconnect color crystal and hilt model. You can of course create two crystals of the same color that link to different hilts to get more variety but something like the system in SWTOR where they're completely independant is not possible. SLM also only adds new color crystals that come with their own unique hilt design and possibly unique color. You could technically replace the vanilla system by doing the following: Add dummy hilt and color crystal items that can somehow be combined to one item that takes the place of the vanilla color crystals and can be inserted into a lightsaber. The problem here is to find a good way of combining these dummy items since we cannot create a new GUI for it or edit the lightsaber upgrade GUI. So this would have to be done with a dialog system on a new workbench which would probably end up being really annoying to use. But if you have a good idea on how to do this, it would be a possibility.

You can also look at other mods that add new lightsaber crystals to the game and see how they work. Then go from there to construct your own mod. One thing to note: In KotOR the hilt model is determined by the color crystal of the lightsaber so it's not possible to have hilts and blade colors that are independant from each other.

Have you tried the ideas proposed in the thread you originally posted in?

We'll need some more information than that. I've been running KAurora without issues on my Windows 7 64bit computer for quite some time, so it's definetly not a pure 64bit issue. I've not tested it on my new Windows 10 64bit computer though.

Vima is done, I was able to recreate robes that look pretty close like the K1 robes (without porting of course). They are not perfect but good enough for a short scene like this. All that's left now is to make the installer with the options to choose between K1 and TSL robes.

Please read this. In short, you can't port hilts (or anything else) from Jedi Academy unless they're mods themselves. In that case you'd have to get permission from the mod author to do so.

All you'd need to do is open PartySwap's holorec.dlg in the dlg editor and then go through all nodes and change "CamVidEffect" from "VIDEO_EFFECT_SECURITY_CAMERA" to "N/A". That would be really tedious but not exactly difficult to do. Or you could use TSL Patcher's ChangeEdit to check for changes in PartySwap's holorec.dlg compared to TSLRCM's holorec.dlg. Then make your own small TSLPatcher that applies these edits to a holorec.dlg file already in the Override and run it after installing the No Overlay mod. You might want to check if any nodes received the overlay while doing that but I doubt it since PartySwap most likely edits the post-recording part of the dialog file. And my download of SLM has no holorec.dlg, no idea why it would in your case.

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

Depending on what you want to do it might be easier to leave the vanilla model alone and add a new model on top of that instead of remaking the entire lightmap. You'd then have to make a lightmap only for the new model and add the model to both the .lyt and .vis file of the module. But that's probably still the easier way to go^^ Or you just wait for the new tools. That's great news!

Quanon is probably right about This being caused by missing lightmaps, but I've also had a similar issue where Models would appear completely black. That was related to me using an older Version of mdlops to decompile Models. Once I switched to The latest 0.7 everything worked fine.

Are The other Files shwoing correctly? If not, is The KotOR file path correct?

You could also try to add Disable Vertex Buffer Objects=0 or =1 to the [GraphicsOptions] of your swkotor2.ini. (I think it needs the spaces but try with and without them.) To be honest I've no idea what this actually does, but it has been known to fix certain issues with the game^^ If someone could elaborate, I'd definetly appreciate it though.

I suggest you use TSLRCM without the workshop just to be safe. It might work otherwise but being close to the end of the game having a game breaking bug that could have been avoided by using another installation method can be really frustrating.

To 1.: Yes, that's what you have to do. Armor/Clothing textures are always named like that and will only work this way.

That UVW map really is straight from hell... I've been trying to use Bastila's texture as a basis for a new one but even trying to remove small leather parts without creating ugly seams is pretty much impossible. Not sure if I'll be able to give Vima a proper texture like that. Any tricks on how to handle UVW mapping like this? Edit: I've been working some more on her texture and I have the upper body pretty much done except for the hands. There are some UVW issues but nothing that will be visible in this mod. The legs are really hard though. Updated Posted 24APR2017, 01:42 AM [Alaska Standard Time] Turns out that Photoshop has a 3d painting feature where I can paint directly on to a 3d model. I used that and now all the seams are gone. Hooray

All the best to you! Both with your medical issues and in your search for a job

That looks like a mod incompatibility where one mod edits the model and another one replaced the texture afterwards, resulting in this mess. But as you still have not provided the answers to the questions I linked in your last topic, I can't do anything to help you find the exact cause.

Please follow the instructions in this post when reporting bugs.

Very well done. Good thing they mostly used cutscenes for the trailer or that would've been a nightmare to create xD

I have both Vima and the Duros Jedi ingame. Now I just need a proper texture for Vima's clothing and also figure out how I can give the Jedi K1 style robes without screwing up their later appearance.

I won't edit the cutscene. These added Jedi masters have no importance for the rest of the game and showing them would only imply otherwise. The same goes for the notes on those other Jedi masters as the list was also downloaded from Atris' archives and she would know whether they live or not. Maybe I'll add a note that they're in fact dead to prevent any confusion about whether or not they are important. About the robes: I was going to give them all K1 robes in different colors for version 2 maybe with an alternate installation option that uses TSL style robes instead. And about the holograms: I've been thinking about that too. I'm just not sure how that will look with TSLRCM's holographic overlay on the entire scene. I'll give it a shot though.

If you could just send me the TSL model and the texture, that'd be awesome. I can then do the 2da editing myself for version 2.0 of this mod.