DarthParametric

Yes, the script exitheart: #include "k_inc_debug" void main() { if (GetIsObjectValid(GetObjectByTag("jolee", 0)) == FALSE && GetIsObjectValid(GetObjectByTag("juhani", 0)) == FALSE && GetGlobalNumber("G_FinalChoice") == 1) { Db_PostString("start conv", 5, 5, 1.0); if (GetIsObjectValid(GetObjectByTag("bastila", 0)) == TRUE) { Db_PostString("bast valid", 5, 6, 1.0); } else { Db_PostString("bast not valid", 5, 6, 1.0); } AssignCommand(GetObjectByTag("bastila", 0), ClearAllActions()); DelayCommand(0.5, AssignCommand(GetObjectByTag("bastila", 0), ActionStartConversation(GetFirstPC(), "unk44_exittrig", FALSE, 0, TRUE))); DelayCommand(1.0, DestroyObject(OBJECT_SELF)); } } I just modified this script last week for the next version of K1CP, which you may wish to use as a basis - https://github.com/KOTORCommunityPatches/K1_Community_Patch/blob/master/Source/exitheart.nss All you'd need to do is remove the check for Juhani. This was a failure on Bioware's part to toggle SetLightsaberPowered back off. I also dealt with this in the K1CP versions of the scene's scripts. Look at the "see also" list in the above link. The computer's OnUsed script (k_punk_comptalk) gates the DLG to prevent its conversation firing before the showdown with Bastila is resolved. The DS route is another simple GetIsObjectValid check. The version you attached won't decompile, so I can't tell what's wrong with it. You need to provide the source (NSS).

Beggars can't be choosers. Besides, the master robe looks ugly.

Your search-fu is weak.

It's either a character length issue or a permissions issue. Have a look at this similar issue someone else had recently and try the suggestions listed - https://github.com/KOTORCommunityPatches/K1_Community_Patch/issues/475

Not entirely true, given the 2DA row limit bug. Multiple installations of any K1 mod that edits placeables.2da will absolutely break it (even just a few mods installed normally will probably push it past its limit) and reinstalling large mods with numerous appearance additions could similarly break appearance.2da. Starting from a clean install is always advisable, especially when installing large and/or multiple mods.

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"....