DarthParametric

An idea regarding the tips/donations crossed my mind, that I'm not sure what the overlords would make of. Rather than asking for direct cash payments such as through PayPal, how about instead asking for Steam gift codes (and/or GOG, if they do that too)? I can see that being less of a headache for the mod author, saves them giving out their personal details and having to deal with potential tax implications of money magically appearing in their bank account.

Not without forcing them to use a custom body model, since players share animations with 90% of other characters. Thus changing the generic supermodels would affect everyone else as well. And in TSL it would probably require additional custom animation for robes.

Assuming you haven't implemented it (or plan to) already, one way of managing the tips thing (which I find a weird nomenclature btw, why not just call it a donation?) might be to add a dedicated field to the mod submission page where the modder can enter a PayPal address or whatever. Maybe with a default message to the effect of "The author has opted out of tips/donations for this mod". It would make it a more consistent enduser experience rather than making them have to ferret through different readmes for the information. And it would keep that junk out of the actual important information about the mod.

Huh, I must be blind. Doing a search through the MDLs though finds no instances of LEH_light11.

Creating a MOD file that goes in the Modules folder. Read the PDF that comes with TSLPatcher for more info.

Note that if you plan on releasing this, for compatibility reasons you'll want to have it use TSLPatcher and ideally set it up for module injection rather than just dump everything in the Override folder.

I fixed the animation issue. It seems that the game didn't like it when reading directly from a modified human supermodel, but when I loaded the anims onto a scaled up Jawa rig they work fine: K1_Jawa_Supermodel_v2.7z The other issue is that none of the Jawa will actually do anything because they lack any default scripts, aside from the OnDialogue one: Adding in all those results in this: I also tweaked the script a bit. It now uses an include script, so you'll need to extract those from scripts.bif and put them in the same folder as the hostile script - k_inc_generic, k_inc_gensupport, k_inc_drop, k_inc_walkways: #include "k_inc_generic" void main() { object oPC = GetFirstPC(); object oJawaA = GetObjectByTag("tat20_06jawa_01", 0); object oJawaB = GetObjectByTag("tat20_06jawa_02", 0); object oJawaC = GetObjectByTag("tat20_06jawa_02", 1); // 10 is considered "high" in vanilla shifts, so I reduced this from 15 AdjustAlignment(oPC, ALIGNMENT_DARK_SIDE, 10); ChangeToStandardFaction(oJawaA, STANDARD_FACTION_HOSTILE_1); DelayCommand(0.5, AssignCommand(oJawaA, ClearAllActions())); DelayCommand(1.0, AssignCommand(oJawaA, GN_DetermineCombatRound())); ChangeToStandardFaction(oJawaB, STANDARD_FACTION_HOSTILE_1); DelayCommand(0.5, AssignCommand(oJawaB, ClearAllActions())); DelayCommand(1.0, AssignCommand(oJawaB, GN_DetermineCombatRound())); ChangeToStandardFaction(oJawaC, STANDARD_FACTION_HOSTILE_1); DelayCommand(0.5, AssignCommand(oJawaC, ClearAllActions())); DelayCommand(1.0, AssignCommand(oJawaC, GN_DetermineCombatRound())); } And one final tweak to the UTCs is that they lack the proper Jawa soundset. Much like the missing scripts, this was due to there never being the intention for them to end up in combat. Oh, and if you want to make UTC changes, be aware that editing them and dumping them in the Override won't work for an existing save. That will require a save before entering the module or otherwise you'll need to edit the save itself, since a module's GIT is included as part of the save, which incorporates the UTC data from any (living) NPCs.

The latest version seems to always revert to the KOTOR 2 format setting when the program restarts, unlike prior versions.

What's the actual texture name? I don't see any LEH_lightXX that matches it. It's entirely possible it is either LEH_light04 or LEH_light06 (most likely the latter) with a coloured self-illum.

Combat animations aren't working yet, but they at least have a death animation now: K1_Jawa_Supermodel.7z

The problem is they count as creatures, so they can't use the standard player animations as-is. They'd need a custom supermodel with all the anims renamed to the creature alternative. It would likely be extremely ropey though, since the rigs don't match at all proportions-wise.

The DS shift worked fine for me, but there was a problem with the script that meant the Jawa wouldn't turn hostile. This is the corrected version: void main() { object oPC = GetFirstPC(); object oJawa; string sJawa = "tat20_06jawa"; AdjustAlignment(oPC, ALIGNMENT_DARK_SIDE, 15); oJawa = GetFirstObjectInArea(); while (GetIsObjectValid(oJawa)) { if (GetStringLeft(GetTag(oJawa), 12) == sJawa && GetStandardFaction(oJawa) != STANDARD_FACTION_HOSTILE_1) { ChangeToStandardFaction(oJawa, STANDARD_FACTION_HOSTILE_1); } oJawa = GetNextObjectInArea(); } } However, the Jawa model lacks any combat or death animations (and has no supermodel), so even though they turn hostile, they just stand there and freeze in place once killed. Looking at the rig, it seems like it might be possible to point it to one of the player supermodels, or at least create a unique supermodel with a subset of required anims. I'll have a play with it.

Best to attach your DLG. It's not really practical to diagnose without poking through it directly.

NWScript is closer to C than C#. You have a few issues there: ExecuteScript is for, as the name suggests, executing other, external, compiled scripts. Declare your sub-functions first, before the main. Seems you have some C# influence going on there. If you want to call a sub-function declared inside the same script, you just use its name, along with any requirements. So, for example, simply CombatOnDialogEnd(oBob, STANDARD_FACTION_HOSTILE_1). You don't need to declare constants like the factions, as they are already declared in nwscript.nss and will be converted as needed by the compiler. The order of your declarations is invalid, again due to C# influence. OBJECT_SELF refers to the script owner, not the PC. Since the script will be fired from a DLG, the owner will be whoever owns the DLG, presumably the hostile NPC (you also don't declare it). That is incorrect use of GetObjectByTag - "GetObjectByTag(string sTag, int nNth=0)". Knowing in advance that the Sandpeople Enclave has multiple instances of the same Jawa UTC that you have to account for, something like this should work: void main() { object oPC = GetFirstPC(); object oJawa; string sJawa = "tat20_06jawa"; // I assume you want a DS shift here AdjustAlignment(oPC, ALIGNMENT_DARK_SIDE, 15); oJawa = GetFirstObjectInArea(); while (GetIsObjectValid(oJawa) && GetStringLeft(GetTag(oJawa), 12) == sJawa && GetStandardFaction(oJawa) != STANDARD_FACTION_HOSTILE_1) { ChangeToStandardFaction(oJawa, STANDARD_FACTION_HOSTILE_1); oJawa = GetNextObjectInArea(); } } Although you may additionally need to give them some prompting to attack the PC, depending on how your initial testing turns out. I'd suggest perusing nwscript.nss, which there will likely be a copy of in your Override if you have used KTool. You should also extract the script source (NSS) available in scripts.bif (via KTool: BIFs -> scripts.bif -> Scripts, Source).

This is a vanilla problem in both games. You'll just have to live with it.

No, they will never be the same because DLGEditor adds a bunch of extraneous crap to every node it edits, plus it adds a custom field that says the file was modified by it and what the time/date was (KTool does the same thing, but across three fields).

There doesn't appear to be any problem with the DLG. And even if there was, that shouldn't cause a crash on loading the module. The MOD seems fine. Doesn't look like anything is missing. The crash is repeatable I take it? If you temporarily remove the MOD from the modules folder, do the crashes stop?

That procedure should work. Post your edited MOD for someone to check.

Well probably best to establish if there is a problem first of all. But assuming there is, you can only have a single head per appearance row, so there's no way to avoid mixing body models using different supermodels if you want that outfit to be wearable (other than a disguise).

Not if it was a full body model as I suggested, where the head is part of the same model. If it is a parts model, like regular clothes/armour, then the head will use whatever supermodel is specified in its model, independent of the body it is attached to.

Hrm, there may be issues then if mixing a head with the vanilla K1 anims with a body with TSL anims. I guess you'll need to test it and see how it goes.

Since she'll need a unique appearance row for this as the DS Grove look (I'm assuming that's the intention anyway), I'd advise changing the names of JC's ported TSL supermodels to something unique (e.g. s_strmjuh_m01, s_strmjuh_f01, etc.) and redirecting the robe model to whatever the renamed equivalent is. Since the head will need to point to them too I would just make it all a single full body model. If you do it that way then you can make it a simple copy and paste option between the too naked and not naked enough versions with no further install requirements. And you won't be overriding the global supermodels which cuts down on potential clashes/incompatibilities, and enduser questions.

Hah, I have to laugh about all those people on Reddit crying about covering her up. If you do want to do an overlaid robe option though, I'd suggest looking at @JCarter426's TSL robes port Cloaked Jedi Robes and grabbing the modder's resource bundle and using that. You should be able to take something like this: and make it work over the top of your existing model, albeit likely with some positional tweaking required. The hooded version is an addition I added for my Dark Jedi Wear Robes mod, which you are free to use as a basis if you wanted a hood option (although you'd have to lop off her top knot and make it a full body model).

No. If you look at the vanilla file, they are commented out, so there was nothing there to begin with. TSL's is the same. Edit: I would advise that you install Notepad++ and grab JCarter's NSS language definitions. That will make reading and editing scripts a whole lot easier.