DarthParametric

Includes are source-only. They don't need to be compiled (and the compiler is hard coded to skip them). Their content is pulled into the compiled script as needed.

Putting commonly/repeatedly used functions into includes makes for less work. Rather than add it directly to the script you are working on, you can just call it via a linked include. You can see the difference in size this can make for even a very simple script when you compare what DeNCS spits out vs the cleaned up version I posted above. Albeit the Bioware compiler adds a bunch of unnecessary guff not actually used in the script. This is why I said above that eventually you'll start to recognise commonly functions. Take a look at sub3 for example. As soon as you spot those cascading GiveXPToCreature calls, you know that's UT_SetPlotBooleanFlag from k_inc_utility, one of the most commonly used functions you'll encounter. So as you comb through those functions and ID them, you can start to change the function names, remove the superfluous function blocks, and rely on linking the relevant include/s.

It does. That's what the giant list of variables and functions is. Calling stuff externally via includes is just for the source to make it easier to parse. When the script is compiled, all those functions are pulled into the NCS.

It's possible that the NWVault has a totally legal copy of it in their "NWN University"....

NWScript is C-like - https://en.wikipedia.org/wiki/NWScript#Syntax As to my scripting abilities, they are fairly meagre, but enough to brute force a solution most of the time. To my own regret, I avoided scripting for most of the time I have been modding. I dabbled on the odd occasion when scripting was the only solution, but typically relied heavily on outside assistance for even the most basic of tasks. It wasn't until I got involved with K1CP that I really started to wrap my head around how scripting works. Almost entirely out of necessity, since probably 80-90% of the content is partially or entirely script-based. I owe a lot to JCarter426 for shepherding me along and answering all my noobish questions along the way. You could say I now know enough to be dangerous. The best way to wrap your head around things is to just look at vanilla scripts and examine how and why they do what they do to achieve their desired outcome. Obviously only global scripts have original source available, and most of those aren't commented particularly well, so initially it can be a bit overwhelming when looking at decompiled module scripts. But eventually you'll start to recognise familiar Include functions and drill down to the meat of a given script. And K1CP has all its source available to peruse, so it's worth having a look at some of those to see how we went about fixing things.

From the Endar Spire's Include - k_inc_end.

If you want to gate via a specific skill rank, then you need to check for that instead: // 315: Get the number of ranks that oTarget has in nSkill. // - nSkill: SKILL_* // - oTarget // * Returns -1 if oTarget doesn't have nSkill. // * Returns 0 if nSkill is untrained. int GetSkillRank(int nSkill, object oTarget=OBJECT_SELF); By the way, your script is bloated because of the Include guff. The cleaned up original script is: #include "k_inc_end" void main() { if (GetIsPC(GetEnteringObject())) { if (HasNeverTriggered()) { SetGlobalFadeOut(); PlayMovie("01A"); SetReturnStrref(FALSE, 32228, 0); //String 32228 is "Return To Hideout". Should instead be 38550, "Transit Disabled". SetGlobalNumber("K_CURRENT_PLANET", 5); SpawnStartingEquipment(); SetGlobalFadeOut(); SetGlobalFadeIn(3.0, 1.5); DelayCommand(0.1, AssignCommand(GetTrask(), ActionStartConversation(GetFirstPC(), "m01aa_c01", FALSE, CONVERSATION_TYPE_CINEMATIC, TRUE))); SetMinOneHP(GetFirstPC(), TRUE); } } } You just want to replace the SpawnStartingEquipment function with your own custom one, but presumably the rest can be pulled from the Includes at compile. However, K1CP made some minor adjustments to the script to fix the player being visible before the first cutscene starts, so I would suggest using that version as a basis instead - https://github.com/KOTORCommunityPatches/K1_Community_Patch/blob/master/Source/k_pend_area01.nss

I'd guess it was probably intended to be some sort of insectoid race.

You don't need compresstexture or downsamplemax. Those aren't TXI semantics, they are for Bioware's internal image processor (i.e. their version of TGA2TPC).

Because the body texture columns in appearance.2da specify a variant base name, not a discreet texture name. The specific variant is specified by the UTI, or failing that it defaults to the 01 variant.

There is also the fact that John Cygan (Canderous) and Robin Sachs (Admiral Karath) are also both dead.

For models like weapons, the texture needs to be specified in the model itself. I don't use Blender, so I don't know how KBlender handles this, but you can always edit the ASCII it exports manually in a text editor. You'll see a bitmap line amongst the various data for the mesh. For example: node trimesh BlstrPst02 parent w_BlstrPstl_003 position 0.0102975 0.131421 0.0833597 orientation 1.0 0.0 0.0 0.0 alpha 1.0 scale 1.0 selfillumcolor 0.0 0.0 0.0 diffuse 1.0 1.0 1.0 ambient 1.0 1.0 1.0 transparencyhint 0 animateuv 0 uvdirectionx 0.0 uvdirectiony 0.0 uvjitter 0.0 uvjitterspeed 0.0 lightmapped 0 rotatetexture 0 m_bIsBackgroundGeometry 0 shadow 0 beaming 0 render 1 dirt_enabled 0 dirt_texture 1 dirt_worldspace 1 hologram_donotdraw 0 tangentspace 0 inv_count 94 bitmap w_BlstrPstl_003 If your mesh doesn't have a texture assigned, it will say NULL.

Sounds like oldflash's movie saber mod: https://www.gamefront.com/games/knights-of-the-old-republic/file/movie-style-replacement-lightsaber-hilts