DarthParametric

Sure, that's just a combination of what I suggested above. I think 9 total is a bit low though. I haven't checked what the actual trigger arrangement is yet, but an alternative approach would be to nix the heartbeat altogether and switch to the triggers each spawning a single group.

The mooks spawned on Deck 2 and Deck 3 both use the same setup (with only minor differences in the UTCs spawned). The module heartbeat that spawns them has a check against a global number (K_STA_HORDE), which stops spawning once it hits 9 and a global boolean (K_STA_SPAWNER) which is an on/off switch. There is a trigger OnEnter that resets the global back to 0, but that has a local boolean check so that it should only fire once. However, on Deck 2 there are three reset triggers and on Deck 3 there are five reset triggers. On top of that, there's a start trigger that also sets the global back to 0 and sets K_STA_SPAWNER true to start the spawning. On Deck 3 there is only one of these triggers (which you'd expect), but on Deck 2 there are five of these, effectively acting as reset triggers. I'd guess these work in conjunction with cutscenes, but I haven't checked that. By my count, that should mean a maximum of 40 mooks on Deck 3 but 56 on Deck 2. You'd need to add a counter script to verify it though, since it's entirely possible that other resets happen during cutscenes. In terms of stopping them, the easiest solution is probably to add a new global number that increments with each spawn and then have it terminate the spawning script once it reaches whatever arbitrary cap you decide on. Alternatively, a less intrusive option would be to simply lower the K_STA_HORDE check value, so the spawner terminates sooner each timer it resets. Edit: So I just did a quick run through with some kill blasters and with a counter added to the scripts. I ran around until they stopped spawning. I got a total of 28 mooks on Deck 2 and 47 on Deck 3. I think I may have hit some reset triggers early on Deck 2, which reduced the count there, but Deck 3 gave me more than I expected, so I gather there must have been additional resets somewhere. Maybe via door OnOpen scripts or something.

Yeah, or just download the whole mod from the releases page and extract the already compiled NCS.

That's k_ptar_takearmor: void main() { DestroyObject(GetItemPossessedBy(GetFirstPC(), "ptar_sitharmor")); CreateItemOnObject("ptar_sithpapers", GetFirstPC(), 1); } I already altered this script to handle multiple sets of disguises as part of a mod request - https://github.com/DarthParametric/K1_Taris_Sith_Uniform_Disguise_Extension/blob/master/Source/k_ptar_takearmor.nss

#include "k_inc_tar" void LockArmour() { object oArmour; oArmour = TAR_StripSithArmor(); if (GetIsObjectValid(oArmour)) { SetItemNonEquippable(oArmour, TRUE); } } void main() { object oEntering = GetEnteringObject(); if (GetIsPC(oEntering)) { DelayCommand(1.0, LockArmour()); } }

Be wary of old tutorials, especially for sabers. The old approach using MDLOps 0.5/0.7 and the Replacer function is no longer valid.

Yes, your model doesn't have any animations. As @Stormie97 said, make sure you choose the appropriate export option in KMax.

No. Do not use subdirectories.

That's outdated. The current version of MDLOps is 1.0.2 and the most recent version of MDLEdit is 1.0.104b. Attach your ASCII for someone to look at to diagnose your problem. The first suspect would be a lack of animations.

Yes, that is the script. Save it as an NSS and compile. You'll also need the includes (k_inc_generic, k_inc_gensupport, k_inc_walkways, k_inc_drop) present as well. If you prefer, here's a pre-compiled one using ActionEquipMostDamagingMelee(), so you should be fine to edit his UTC however you like with no further changes. k37_sha_hostile.ncs

That was the trigger OnEnter that starts his conversation. Per kor37_shaardan.dlg, the script that turns him hostile is k37_sha_hostile, which cleaned up is: #include "k_inc_generic" void main() { object oSpeaker = GetPCSpeaker(); ChangeToStandardFaction(OBJECT_SELF, STANDARD_FACTION_HOSTILE_1); object oSword = GetItemPossessedBy(OBJECT_SELF, "G_w_VbrDblswd01"); if (GetIsObjectValid(oSword)) { ClearAllActions(); ActionEquipItem(oSword, INVENTORY_SLOT_RIGHTWEAPON, FALSE); } DelayCommand(0.5, GN_DetermineCombatRound(oSpeaker)); SetGlobalNumber("KOR33_SHAARDAN", 4); } I usually just give him a fake sword, which is far more amusing, so I don't think I've ever actually had him turn hostile. But I can see straight away that this is probably going to lead to the very common attacking with fists issue. A change in the order of operations should help prevent that, something like this: #include "k_inc_generic" void main() { object oPC = GetFirstPC(); object oSword = GetItemPossessedBy(OBJECT_SELF, "G_w_VbrDblswd01"); SetPartyLeader(NPC_PLAYER); if (GetIsObjectValid(oSword)) { ClearAllActions(); ActionEquipItem(oSword, INVENTORY_SLOT_RIGHTWEAPON, FALSE); } DelayCommand(0.4, ChangeToStandardFaction(OBJECT_SELF, STANDARD_FACTION_HOSTILE_1)); DelayCommand(0.6, GN_DetermineCombatRound(oPC)); DelayCommand(0.6, AssignCommand(oPC, GN_DetermineCombatRound())); DelayCommand(0.6, AssignCommand(GetPartyMemberByIndex(1), GN_DetermineCombatRound())); DelayCommand(0.6, AssignCommand(GetPartyMemberByIndex(2), GN_DetermineCombatRound())); SetGlobalNumber("KOR33_SHAARDAN", 4); } This is probably something we need to investigate for K1CP. If you are planning on changing his gear, I'd suggest just switching the equip command to ActionEquipMostDamagingMelee() instead, like so: #include "k_inc_generic" void main() { object oPC = GetFirstPC(); SetPartyLeader(NPC_PLAYER); ClearAllActions(); ActionEquipMostDamagingMelee(); DelayCommand(0.4, ChangeToStandardFaction(OBJECT_SELF, STANDARD_FACTION_HOSTILE_1)); DelayCommand(0.6, GN_DetermineCombatRound(oPC)); DelayCommand(0.6, AssignCommand(oPC, GN_DetermineCombatRound())); DelayCommand(0.6, AssignCommand(GetPartyMemberByIndex(1), GN_DetermineCombatRound())); DelayCommand(0.6, AssignCommand(GetPartyMemberByIndex(2), GN_DetermineCombatRound())); SetGlobalNumber("KOR33_SHAARDAN", 4); }

This was clearly using a Korriban module include, but that is not present in the source files. Here's the vanilla script: #include "k_inc_utility" void SetShaardanFlag(int nState) { UT_SetPlotBooleanFlag(OBJECT_SELF, SW_PLOT_BOOLEAN_01, nState); } int GetShaardanFlag() { return UT_GetPlotBooleanFlag(OBJECT_SELF, SW_PLOT_BOOLEAN_01); } void main() { object oPC = GetFirstPC(); object oNPC = GetPartyMemberByIndex(0); object oShaardan = GetObjectByTag("kor37_shaardan", 0); if (GetShaardanFlag() == FALSE && GetEnteringObject() == oNPC && GetIsObjectValid(oShaardan)) { SetShaardanFlag(TRUE); UT_NPC_InitConversation("kor37_shaardan", "", OBJECT_INVALID); } } But I would suggest streamlining it to: #include "k_inc_utility" void main() { object oEntering = GetEnteringObject(); object oShaardan = GetObjectByTag("kor37_shaardan", 0); if (!UT_GetPlotBooleanFlag(OBJECT_SELF, SW_PLOT_BOOLEAN_01) && GetIsPC(oEntering) && GetIsObjectValid(oShaardan)) { UT_SetPlotBooleanFlag(OBJECT_SELF, SW_PLOT_BOOLEAN_01, TRUE); UT_NPC_InitConversation("kor37_shaardan", "", OBJECT_INVALID); } }

The only route would be via making them disguises, but that's a pain in the ass for separate bodies and heads.

The vanilla game only uses RIMs for module files (and ERFs for DLGs in TSL). Any MOD files there are from whatever mods you have installed. The only place the vanilla game uses MOD files is in the Lips folder.

You can check out the rigmarole I had to go through to get Carth to co-operate with the hide flags in the post-Leviathan scene for K1CP. It required some reworking of the DLG.