DarthParametric

Modders
  • Content Count

    4,607
  • Joined

  • Last visited

  • Days Won

    521

Everything posted by DarthParametric

  1. I did a quick test on Korriban and it seems to work fine. I have added it as an optional download to the mod's page.
  2. I have no idea. But any mod that adds new holograms will presumably use vanilla clothing Bastila.
  3. I haven't tested it, but try this: [TSL]_Fixed_Hologram_Models_and_Admiralty_Redux_for_TSLRCM_DS_Bastila_K1_Robes_Patch.7z Install the previously linked Fixed Holograms mod first, then extract the model and texture from the attached archive and put them in your Override folder, overwriting when prompted. Should replace the DS Bastila holos on Korriban and on the Hawk (when talking to T3).
  4. That mod is useful as a basis, since it gives her a unique DS appearance with a custom model (DP_BastilaDS.mdl/mdx). Makes it easier to edit if you wanted the K1 robes.
  5. Tedious more than hard, but that's a problem for @Stormie97 to worry about.
  6. The stunt animations for those scenes will need the eyeball and eyelid keyframes to be tweaked.
  7. Not without re-rigging the model to the TSL skeleton. Not something I have any interest in bothering with. And the TSL animations have no provision for a cape or the front flappy bit, so it would be a waste of time anyway.
  8. I haven't tested it in TSL, but in K1 the workbench always defaults to the player's appearance row to determine the armour models that are displayed for each armour class. So presumably the only time companion clothing would show up is when you switch to controlling Mira on Nar Shaddaa, where it should show her jacket.
  9. Use this instead: // 534: Get the tag of the key that will disarm oTrapObject. // - oTrapObject: a placeable, door or trigger string GetTrapKeyTag(object oTrapObject); Although neither function is used by vanilla scripts in either game.
  10. TSL has the companions always try to stay within 10-15m (off the top of my head) of the controlled character. If they are too far away, they get jumped back. I have tried to implement this in K1 a couple of times, but it's not practical to do it the way TSL does it, as they added additional functionality for it. That's why I created this when I was doing K1CP beta testing.
  11. This appears to be backwards. N_CommMD/FD01 is 512x512 while N_CommM/F07 is 256x256. The dirty commoner appearance rows use the MD/FD for their texa/texb columns while Gendar's unique appearance row uses just M for his texa/texb columns. K1CP ports the TSL versions of N_CommM/F07 which are 512x512. Edit: I realised that K1CP erroneously replaced N_CommF07/M07 with TSL's F11/M11, which is the dirty version of their repainted F01/M01. That has been revised to renamed copies of FD01/MD01 for v1.10.
  12. They are talking about a Jingasa, i.e.: The Embo referred to is some Clone Wars character: TOR has that style of thing, albeit including a full helmet underneath, which could be used as a basis if needs be. Not that a simple dome shape would be hard to model from scratch: But helmets and hats don't work particularly well in KOTOR due to the way heads and hair work. Although if you only want it for use with one specific player head then it's doable.
  13. In the meantime, me, working on K1CP v1.9:
  14. Well technically it is something you (or @Marius Fett) could fix. The model just needs adjusted die/dead/getupdead and/or die1/dead1/getupdead1 anims. It actually shouldn't be too arduous if it is just some arm/hand adjustment, since you can just fix the static dead anims first and then reuse those keys as the end/start frames for the die/getupdead anims.
  15. Seems like someone forgot to null out some SendMessageToPC debug messages before pushing the release version.
  16. Not without renaming the eye mesh to match the vanilla name (Mesh01).
  17. Yeah that's the one. I guess it works fine on that side since the doors don't close until you re-enter the module, so you shouldn't end up locked out.
  18. You could use GetNearestObjectToLocation: // 228: Get the nNth object nearest to lLocation that is of the specified type. // - nObjectType: OBJECT_TYPE_* // - lLocation // - nNth // * Return value on error: OBJECT_INVALID object GetNearestObjectToLocation(int nObjectType, location lLocation, int nNth=1); Another option might be ObjectToString: // 272: Convert oObject into a hexadecimal string. string ObjectToString(object oObject); I think that should be a unique value, but I only ever tried it once and not for use with multiple instances of a single template. Even if it is unique, I suspect it would not be universal across installs, or perhaps even individual sessions on the same machine.
  19. No, you can't return the nearest object as OBJECT_SELF. Presumably that's why the nth index starts at 1 and not 0.
  20. Something you may want to consider for a future update, since it doesn't appear you have already addressed it. The selection icon to open the door before the hangar (accessing the transition trigger in the vanilla module) floats out in the middle of the corridor due to the walkmesh restricting access to it if you move it across the panel cluster on the wall. You could add one of the perpendicular panels that the other doors have to alleviate this. An idea I rejected for K1CP for being out of scope, but perfectly suited to this mod.
  21. Make sure that w_dblsbr_001.mdl.ascii is in the same folder as the batch file. It uses those to generate the other files. Then compile them as JC said above.
  22. GetIsDead is what you'd typically use. // 140: * Returns TRUE if oCreature is a dead NPC, dead PC or a dying PC. int GetIsDead(object oCreature);
  23. You're probably looking for the YavinHackCloseDoor function's comment, which is in nwscript.nss: // 771. YavinHackCloseDoor // This is an incredibly hacky function to allow the doors to be properly // closed on Yavin without running into the problems we've had. It is too // late in development to fix it correctly, so thus we do this. Life is // hard. You'll get over it void YavinHackCloseDoor( object oidDoor );
  24. That's known as a "sub-mod" in the parlance of other mod communities. It's fine as long as the bone count isn't 18 or above. The MDL format supports up to 17 bones per mesh (Vandar being one of two vanilla K1 models that max out the limit). Early versions of MDLEdit erroneously declared the limit at 16, but I believe this was changed in later versions.