DarthParametric

Leaving aside the fact that I thought the entire point was to add new banter, not replace the existing ones, how do you expect me to know what's wrong when you haven't even said what you have done and provided the scripts, DLG, etc.?

MDLEdit decompiles a binary model into memory when loaded, so there's no need to generate physical ASCIIs unless you intend to load them in Max/GMax. I don't believe MDLOps supports the Xbox format, no. Perhaps @seedhartha could be convinced to add Xbox support to KBlender (which now imports/exports binaries directly) if you ask nicely. I'm not familiar with the differences between the PC and Xbox formats, so I couldn't really say what in particular could be causing issues. The only time I have seen something similar is with ye olde MDLOps mangling meshes, so my guess would be that MDLEdit is doing something incorrectly for those models for some reason.

There's no reason it shouldn't run under Win 10. It requires Java though, which is less than ideal. You could always spin up a Win 7 VM and run it under that if you want to contain the taint. Edit: Added the Upari amulet fix to K1CP - https://github.com/KOTORCommunityPatches/K1_Community_Patch/blob/master/Source/k_pkas_hurtgive.nss

You really should just grab DeNCS. void main() { object oPC = GetPCSpeaker(); object oCrystal = GetItemPossessedBy(OBJECT_SELF, "kas25_wookcrysta"); ActionGiveItem(oCrystal, oPC); } The problem is the UTC doesn't actually have the item in its inventory. They used ActionGiveItem because that makes the NPC walk to the PC and do an animation, but it needs to either be switched to a CreateItemOnObject directly spawning it into the PC's inventory, or it needs to first be spawned into the Wookiee's inventory and then given to the PC, or the Wookiee's UTC needs to be edited to add it. If you find a problem that either Community Patch doesn't address, you can just raise an issue for it on the repo. I've added this one (and I also see an issue with the heal scripts).

Since you can't actually add new companions, just replace the vanilla ones, I assume he's using either Jolee, Juhani, Zaalbar, or HK's slot? As such he will potentially incorrectly trigger certain vanilla banters because the script only checks the character slot is active in the party, not what the tag of the actual NPC is. You'll probably need to add a tag check to prevent the appropriate vanilla banters accidentally firing, if there are any. And, likewise, also add a tag check to only trigger your new ones correctly. I haven't looked at the DLG or the associated scripts (I gather that's what the starting conditional script in the first post is), but I assume it is setting the appropriate global to true once a given scene has started, so you'll need to replicate that behaviour as well for your added DLG nodes.

Creating new globals is as simple as adding them to the end of the 2DA. It will require starting a new game for them to work though. Adding extra custom conditions to trigger your banters will require editing the k_bant_trig script. I'm not sure how many total triggers are in the game, so keep in mind that adding additional banters means potentially reducing the likelihood of seeing vanilla banters, since each trigger will only fire once (unless you change the TALKED_TO local boolean checking/setting in k_bant_trig).

As the script says, it's a global boolean. Or technically 11 booleans. The globals are defined in globalcat.2da. The banters are fired by triggers in various modules. They should all use the same global trigger template, k_bant_trig.utt which uses the global script k_bant_trig as its OnEnter. Since 11 cases already exist for vanilla banters, you'd need to add new globals and new conditions for your added banters.

The ones in the archive are just the vanilla scripts so you don't need any special permission. You can credit me for supplying them if you want, but all I did was decompile them and tidy them up a bit so it's really Bioware's work not mine. For compatibility purposes we encourage people to look at K1CP's source, available here, which people are free to use as a basis for their own mods as long as credit is provided. You are likely running it from inside Program Files. Don't put/install anything there and your life will be much easier. Windows is particularly bitchy about permissions there.

Module scripts only exist as binaries. They need to be decompiled. Currently the only option is DeNCS - https://web.archive.org/web/20160405105949/http://starwarsknights.com/mtools/DeNCS.zip Attached are the vanilla module scripts that I have already previously decompiled and cleaned up while working on K1CP. unk_m44ac_Lehon_Temple_Summit_Selected_Source.zip

You say that like I'm supposed to know what it is, but I gather from your subsequent comment that the game is running under a 360 emulator. Assuming everything else is working correctly, it's mostly likely a MDLEdit issue with the conversion. Make sure you are using the most recent beta version, not the outdated one from the official release thread.

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: