DarthParametric

Your problems are straightforward. In the first instance, you haven't declared the variables properly. Per nwscript.nss: void RemoveJournalQuestEntry(string szPlotID); Since the plot ID is a string it must be inside double quotes, like so: RemoveJournalQuestEntry("tat_IzizCaptive"); Note that this function removes the quest, as stated - i.e. deletes it entirely. Typically you will want to advance a quest to a closed stage, assuming one is available, so that it is still viewable by the player in the completed quests tab. You can do that with: void AddJournalQuestEntry(string szPlotID, int nState, int bAllowOverrideHigher=FALSE); Where you state the state number you want. The final TRUE/FALSE variable allows you to override a high numbered plot state (e.g. 90) with a lower number one (i.e. 20) if that is required. Typically it's not needed, but there are a handful of vanilla quests that have low numbered end states. If you are making your own custom quests, as seems to be the case here given the plot ID, then you can avoid that being a problem by using incrementing state numbers with the ending/s using the highest value/s. If instead you are trying to deal with the vanilla quest, its plot ID is tat17aa_jawarescue (all the quests are found in global.jrl). Also note that quest states can be set directly via a DLG, as is the case here when talking to the Jawa you free in the Sandpeople Enclave. For the second instance, as the compiler error stated, you have an undeclared variable, oPC. You either need to declare it in your script, like so: object oPC = GetFirstPC(); Or simply change your existing line to: GiveXPToCreature(GetFirstPC(), 250);

Cool. I'm looking forward to finally being able to decode some of those holdout scripts that still remain impervious to DeNCS's charms (like some of the Star Forge level 4 ones for example). If you manage to release something before the end of the year we can clear out the last of the remaining hijacked scripts in K1CP before v1.9 releases.

There's a rollout for the OdysseyBase where you can edit the supermodel, the same as in KMax. Blender's way of doing things is just a lot more clunky and obtuse.

The only significant workflow change is that you'll be able to drop MDLEdit and the ASCII to/from conversion. Everything else will remain the same. Once the importing of vanilla normals is implemented, that will solve some shading problems that can happen currently due to the smoothing group approach. But it won't fundamentally change anything about how handling models works.

Note that taking MDLEdit out of the loop doesn't change anything else. You'll still need to rerig most models when switching from one game to the other.

So does this mean that KBlender will be able to import/export the model's original normals directly rather than dealing with MDLEdit/KMax's hacky conversion to/from Max smoothing groups (which is a legacy of MDLOps/NWMax's ASCII format)? Because that is the single biggest problem with the current Max/GMax workflow, causing all sorts of broken shading issues, especially on head models.

It has been a while between drinks, what with the last (full) release of K1CP coming out in 2019. So with the end of 2021 rapidly approaching, it's time for another status update. I'm targeting a release for v1.9 somewhere around Xmas, assuming things go to plan. There are still two full pages of issues on the Github repo, but not all of those are destined to be fixed in time for the next release. And no doubt I'll pick up a few new issues while beta testing, which I'll probably start in mid- to late-November. Here's the current changelog:

Not sure if you got this one or not (I didn't turn up anything in a search): 40047 - "Take an old man's advice, Yuthura. I know the Jedi aren't as perfect as they think they are, but they're way is a lot better than the way of the Sith." Should be their.

Exactly what it sounds like. Batch does the operation on a group of selected files. The other option is for a single file.

Whoops, syntax error on my part. The If statements have their closing brackets in the wrong place. The example I posted above should be: if (GetSkillRank(SKILL_COMPUTER_USE, GetFirstPC()) > 0) { CreateItemOnObject(COMP_PART,oLocker, 2); }

Try changing the check to: if (GetSkillRank(SKILL_COMPUTER_USE, GetFirstPC())) > 0 { CreateItemOnObject(COMP_PART,oLocker, 2); } I would assume that inherently the GetHasSkill check should already be checking for a skill rank greater than zero, but perhaps not. I'm pretty sure I suggested this already the last time this came up.

No, it's not an include. I meant that if you were distributing a mod, you'd have to include K1CP's k_pend_cut02.ncs as well because of the changes I listed above. If you are just making something for your own use and already have K1CP installed then you don't need to do anything. Although I would advise in future not using content from MODs as a basis. Extract the RIMs instead. Start with the vanilla content, then check if something like K1CP modifies it afterwards. Not necessarily. Modifying the UTC is certainly one route, but you can also just give him items/equip them via script. Remember that modification of assets that are already stored in the save file (i.e. GIT, spawned NPCs, triggers, etc.) will require restarting the module over again. Scripting is therefore very useful for testing at least, even if you want to end up editing a UTC, etc.

Looks like you are using the K1CP modified version there @ebmar. The vanilla script has a slightly different case 10 that introduces a slight hiccup in Bandon's walk forwards. You should use the K1CP version as a basis, I'm just clarifying the situation. Edit: However, you must use this in conjunction with K1CP's k_pend_cut02, or you will end up with a soft-lock that prevents the cutscene from proceeding.

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.