DarthParametric

Modders
  • Content Count

    4,607
  • Joined

  • Last visited

  • Days Won

    521

Everything posted by DarthParametric

  1. 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.
  2. 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.
  3. 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.
  4. It has nothing to do with this mod. The likely cause is some mod altered the Alien_Mandalorian_03 row of appearance.2da, some mod altered the N_Mandalorian03 texture, or some mod changed his UTC (or some combination thereof).
  5. 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?
  6. It's an enduser issue, not the mod. It's a problem with your GPU not handling normal maps. You presumably have an integrated GPU or some other low end part. This is literally spelled out in the mod description above.
  7. Seeing as how K1CP doesn't even touch sta_m45ad, the final module, your problem is almost certainly user error.
  8. The world is a big place. It's only early evening in my neck of the woods.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Probably, but that's not something I track and it's really not germane to the topic at hand.
  14. Yeah that was for the Telos skybox. As you might expect, the Malachor skybox model is the one you didn't check, MalB. Make sure you are using the most recent version of MDLEdit, available here.
  15. I'd assume that would work the same way rain would, with VFX nodes (which is what I was expecting). Malachor just uses simple planes with a room animation dialling the mesh alpha up and down.
  16. TSL usually makes its skyboxes fairly obvious. In this case, "sb" is the identifier, although in other cases they use "sky". As to tools, you could theoretically do it all in a text editor like Notepad++, but in practice that's not really going to work. You'll need to load up the whole module in either Max/GMax or Blender. You could just reuse the Malachor planes, since they are already UV mapped and ready to go. Then you'd just need to position them. I haven't looked at 233, but 231 already has an A node, 231telSBa, which the forcefield and the bird emitters are under.
  17. There are a couple of ways you could do it, but Malachor uses the simplest method - static planes with animated textures: You'd need to edit the skybox model for whatever module you want to add them to, create some planes with their normals facing inwards towards the player, enable some self-illum on the Trimesh modifier, and make them children of the A node (a dummy object that is a direct child of the OdysseyBase that has the same name with an additional "a" appended - this is required for animated objects to work).
  18. Now the only question is, how much would you pay to finally live out your childhood fantasy and get one for yourself?
  19. It wasn't deleted. Your posts are in the WIP thread. If you want to report something and actually have a chance that someone (i.e. me) will actually notice/remember it, create an issue on the Github repo. If it's not on that list, it's not going to get addressed.
  20. The mod only has provision for the vanilla female player heads in heads.2da and the associated player rows in appearance.2da. Retextures or model edits/swaps are irrelevant if they don't affect the row ID. Added female heads are not supported. The male version will work for any head, included custom added ones, as long as the vanilla PMBJ models are specified in appearance.2da.
  21. Since TOR released a set of the Star Forge robes not too long back, I figured it might be a useful basis for a hybrid version with the vanilla cape and loincloth (the TOR version is only painted on) married to SS's flowing robes animations. At this point I've done the initial import, scale, and pose, and am now ready for the transfer to the KOTOR rig. Thanks to the Blender I/O script, I was also able to bake out the tinted textures, which is much easier than trying to approximate it manually as I have had to do in the past. Here's where it's at currently: I still need to fiddle with a few bits and pieces, and there will no doubt be plenty of tweaking to do once the rig transfer is done and I can test out animations. I also have some folded down hoods taken from other sets that I will try to marry to this torso for a hoodless/maskless version. But that will require a fair bit of massaging to get them to fit, so I'm saving that for later. Still not sure about the cape. I think having it white as well would be a bit too overpowering, but I'm not entirely sold on the brown. And I haven't done anything for the DS black version as yet. Since there's no TOR version of that colour scheme for this set, I'll have to cobble something together myself.
  22. I won't be making any further changes/additions to this mod. But I may have an alternative option at some point in the nebulous future.
  23. Not really, no. All the early companion/NPC outfits they did, of which the Calo set was a part of, were pretty so-so. Some are better than others, but most take a bit too much artistic license for my taste. The recent "Jedi Knight Revan" (i.e. the Star Forge robes) outfit is probably the best KOTOR set they have ever done, albeit not perfect: Only took them a decade to get it right.
  24. It's a pretty poor interpretation of the KOTOR version: