DarthParametric

I couldn't really say. I don't use Blender since it was made by aliens and is completely inscrutable.

K1CP doesn't touch Rukil's DLG, or any of his scripts, so it shouldn't be that. You only have two other options. Either some other mod is directly editing those, or has broken the MOD.

Ah, I see the problem. The starting conditional in question is k_ptar_rukil10+. Not sure which one it is, but you are using a mod that is editing tar_m04aa.mod with an old version of TSLPatcher that has a bug that causes it to delete any files with characters like + in the filename when it repacks the MOD. This issue will affect multiple modules throughout the game, as Bioware used that convention a lot. One example from experience with my own mods is the Upper City Cantina. K1CP uses a fixed version of TSLPatcher that resolves this bug, but Fair Strides never publicly released it as far as I am aware, and it's only a few years old anyway. The only way to resolve it is to start again from a completely fresh install and replace every single mod's copy of TSLPatcher.exe with the one from K1CP (renamed INSTALL.exe) before installing any of them. You'll want to go through your mod list and see which of them (aside from K1CP) edits tar_m04aa.mod and inform the author/s of the issue and the solution.

Open your save in KSE and go to Globals -> Numerics. Check what the value of Tar_Rukil is. And presumably you still have all 3 journals in your inventory?

I had a quick look and didn't seen anything noteworthy. The mooks use the generic global scripts, and Jagi just has an OnDeath event that pops the journal update. The UTCs don't show anything obvious either. If you haven't tried AssignCommand for Jagi like you would have done for the mooks then I would try that. Otherwise nothing else immediately springs to mind.

Maybe something in their UTC or OnSpawn.

If it's Jagi then I assume this is during the Dune Sea showdown? I've never used the function myself, so I have no particular insights to it. At a guess, I'd assume it only functions after combat has been initiated. If you want a fancy cutscene, you're probably better off just doing what I said above and faking it.

Is the guy with the shield the DLG owner?

The conjanim column will likely be referring to the VFX hook (handconjure in this case), not the animation. If you want them to activate a shield, it's probably easier to just fire the anim (ANIMATION_FIREFORGET_ACTIVATE) and then apply the shield VFX. Edit: Ah, there's an include function for it - GN_ActivateForceField(). Organic Shields are 99 to 107 Droid shields are 110 to 115 Scans through all of the shield talents to see if the target has a shield to use. If the shield is used then the person will never use another one. Party members will never use this function.

Typically this is the correct approach, however there are some exceptions, notably when another does hard MOD overwrites. K1CP's installation instructions explicitly state this: The most common culprit is NPC Overhaul, but obviously there are others.

K1CP doesn't replace MODs. No mod should. The entire point of using a MOD is to inject changes for maximum compatibility. I have no idea what SotOR is. Have you identified any actual hard conflicts? For example, both mods replacing a particular script.

Don't worry, he'll be back.

Interesting. I can't claim to have gone through all the K1 scripts (not least because some still can't be decompiled), but in the course of working on K1CP have browsed one or two and I have never come across this one. I did a quick search through the global scripts and found a use of it in TSL's k_inc_force. Is it a TSL-only thing?

The world is a big place. It's only early evening in my neck of the woods.

Simply changing a model's filename is bad practice. The model's internal OdysseyBase name will still retain its original name, and this can end up causing conflicts, since this is what the engine uses to instance models in a level. As to the texture itself, the texture specified in the model is irrelevant in this case, since what texture is actually used in the game is determined by the appearance.2da entry, which overrides anything in the model. If you want the DS model to use the LS texture, you can either edit its appearance.2da row and change the texture specification from "N_DarthRevan" to "N_StarForgeA" (I believe it is using the RaceTex column), or you can simply make a copy of N_StarForgeA01 and rename it N_DarthRevan01.

The DS robes just use the vanilla Revan texture, N_DarthRevan01. The LS robes use the texture added by the mod, N_StarForgeA01. What exactly did you rename and replace? The models? You can restore the originals by copying the MDLs/MDXs from the mod's archive and pasting them into the Override folder.

Since the player's version of the Revan robes has a unique slot in appearance.2da (the J slot), you shouldn't really need to do any model alteration. Assuming this is the mod by Grey_Ghost, a cursory glance at the description seems to indicate it doesn't touch the J models or textures, so you should be able to just duplicate his textures and rename them PMBJ01 for the DS variant and PMBJ02 for the LS variant. That's if you want to use them for the vanilla J models, which is how I interpret the above. If not, you need to provide more precise detail about what you want to do.

Textures don't have a path specified in the model, only the filename. By default, vanilla textures are pulled from the appropriate ERF files in \TexturePacks\. However, any texture with the same name in the Override folder will, as the name suggests, override the vanilla texture. If you just want to replace the vanilla texture with an edited one, putting it in the Override is all you need to do. If you want/need to change the filename, you have two options (well three if you include editing the model in Max/GMax or Blender, but you've ruled that out). You can decompile the model using either MDLEdit or MDLOps. The former will let you edit the name while the model is loaded into memory, the latter will require editing the exported ASCII model in a text editor (which you can also do via MDLEdit). Then the model would need to be recompiled. This is not particularly desirable for character models, because both tools have problems with losing the vanilla vertex normal (i.e. smoothing) data, which can result in shading errors, especially for head models. The other option is to edit the model in a hex editor and change the texture reference/s in the binary model directly. This has the benefit of not breaking the smoothing, since it doesn't alter anything else. Whichever route you go, you place the edited binary models into the Override, alongside your new texture. Note that there may be additional options, depending on what exactly you are trying to do. In TSL for example, you can override a head texture assignment by editing heads.2da (K1 lacks this provision though). You should provide more information on your objective.