DarthParametric

You'd be better off editing the UTS, since that will allow you to customise specific instances without affecting use of it globally. But if you're lazy, the WAV is in streamsounds. Note that it is an actual WAV with fake MP3 headers, so you'll want to strip those first with SithCodec before editing it (and use it to re-add them afterwards).

Btw, I just realised what the problem with your original script was. if (nPersuade = 0) should have been if (nPersuade == 0) Not sure how I missed that.

This version works. Tested it with Eli's store. I've added some debug elements to it to post info to the Feedback screen via SendMessageToPC, which you'll want to remove in the final version. void StoreOpen(object oMerch, object oNPC, int nMarkUp, int nMarkDown, int nSkill) { SendMessageToPC(oNPC, "PC's Persuade = " + IntToString(nSkill)); SendMessageToPC(oNPC, "nBonusMarkUp = " + IntToString(nMarkUp)); OpenStore(oMerch, oNPC, nMarkUp, nMarkDown); } void main(){ object oPC = GetFirstPC(); int nPersuade; int nPersuadeAdj; AssignCommand(GetFirstPC(), ClearAllEffects()); nPersuade = GetSkillRank(SKILL_PERSUADE, oPC); if (nPersuade > 0 && nPersuade <= 17) { nPersuadeAdj = nPersuade - 10; } else if (nPersuade > 17 && nPersuade <= 30) { nPersuadeAdj = (2 * nPersuade) - 27; } else if (nPersuade > 30) { nPersuadeAdj = 33; } else { nPersuadeAdj = -10; } DelayCommand(0.1, StoreOpen(GetObjectByTag("kas_czerkastore", 0), oPC, (nPersuadeAdj * -1), 0, nPersuade)); } Declaring the skill has been moved to after the ClearAllEffects, since I presume you are trying to remove buffs first.

1 * nPersuade is just nPersuade, so I'd drop the superfluous 1 *. As to nBonusMarkUp = -nPersuadeAdj, I'd try nBonusMarkUp = (nPersuadeAdj * -1) instead. void main(){ object oPC = GetFirstPC(); object oStore = GetObjectByTag("kas_czerkastore", 0); int nPersuade = GetSkillRank(SKILL_PERSUADE, oPC); int nBonusMarkUp; int nPersuadeAdj; AssignCommand(GetFirstPC(), ClearAllEffects()); if (nPersuade = 0) { nPersuadeAdj = -10; } else if (nPersuade > 0 && nPersuade <= 17) { nPersuadeAdj = nPersuade - 10; } else if (nPersuade > 17 && nPersuade <= 30) { nPersuadeAdj = (2 * nPersuade) - 27; } else if (nPersuade > 30) { nPersuadeAdj = 33; } nBonusMarkUp = nPersuadeAdj * -1; DelayCommand(0.1, OpenStore(oStore, oPC, nBonusMarkUp, 0)); } Have you tried using the nBonusMarkDown term in OpenStore by the way? Seems like that's what it should be for, rather than using a negative value for nBonusMarkUp (even though I see vanilla scripts do that).

You could try running it under Wine or something like that. Or perhaps @JCarter426 can upload the source and you could try compiling it for Mac. A random sample from K1 suggests 32,000 Hz, 48 kbs - NM11AAGADO02016_.mp3

A DLG will always initiate the first available branch. The way a vanilla DLG is ordered is that early branches all have starting conditionals, which allows the engine to fall through them until it reaches one with a valid condition. Failing that, it reaches the final branch which doesn't have any starting conditional. If you add new branches under this branch (typically Entry 0), they will never fire. You need to move your added branches higher up the tree and give them an appropriate starting conditional so they only fire under the correct circumstances. This may require the addition of new globals, depending on what exactly it is you are trying to do.

If you only weight it to the head (as you would have to in a separate head model) then they will be completely rigid and clip through the body with even the slightest head movement. Danglymeshes will also clip. I figured there wasn't much likelihood of a sim being practical, so that's fine. Thanks for giving it a shot though.

No, Xor will not appear on Dantooine. Doing so would require editing the messengers include function and then recompiling the messenger trigger script in the Enclave module. Note that K1CP already edits this script.

Typically you do not want to be editing module OnEnters outside of for personal testing purposes unless it is absolutely required. It's terrible for compatibility purposes. For a mod that is to be publicly released, you'll want to instead rely on other methods. For NPCs that should always be present, simply adding it to the GIT's creature list is the way to go. For NPCs that need to spawn under specific scenarios, adding a trigger with a custom script would be preferable to editing the OnEnter. Or as LoneWanderer suggested, a DLG is a common vector, primarily when the NPC appears during, or as a result of, a cutscene/conversation.

Those were pulled in from the include files by Bioware's compiler. Just as nwnnsscomp does, all the constants in any listed includes get pulled in, even if they aren't actually referenced by the script. But you can't just blindly delete them every time. Sometimes they will be used (or some of them anyway), most commonly when referencing local boolean constants from k_inc_utility (SW_PLOT_BOOLEAN_01, SW_PLOT_HAS_TALKED_TO, etc.). But anything to do with AI will typically reference a bunch from multiple different includes.

Both scripts are for the DS route and fire consecutively (as you can see for yourself in unk44_evilbast.dlg). The first one is k_punk_bastjoin, which removes Jolee and Juhani from the party and spawns a level-appropriate Bastila (determined by the player's current level). Then k_punk_bastjoin2 adds the new evil Bastila to the party (the stunt Bastila you've been interacting with up to this point is then destroyed on the DLG exit node). Btw you don't need all that include garbage in your script. A clean version of the original is simply: void main() { ActionPauseConversation(); AddPartyMember(NPC_BASTILA, GetObjectByTag("bastila", 0)); ActionResumeConversation(); } Note however that K1CP makes some minor alterations to this script, which you'll want to include for compatibility purposes - https://github.com/KOTORCommunityPatches/K1_Community_Patch/blob/master/Source/k_punk_bastjoin2.nss Your problem with the equipping can likely be resolved simply by a change in the order of operations. Try the following (K1CP additions incorporated): void AddBast(object oNPC) { AddPartyMember(NPC_BASTILA, oNPC); } void main() { object oBastila = GetObjectByTag("Bastila", 0); object oJolee = GetObjectByTag("jolee", 0); object oJuhani = GetObjectByTag("juhani", 0); object oDblSbr = GetItemPossessedBy(oBastila, "g_w_dblsbr002"); object oBastSbr = CreateItemOnObject("bast_dblsbr_151", oBastila, 1); ActionPauseConversation(); AssignCommand(oBastila, ActionEquipItem(oBastSbr, INVENTORY_SLOT_RIGHTWEAPON, TRUE)); DelayCommand(0.2, DestroyObject(oDblSbr)); DelayCommand(0.4, AddBast(oBastila)); // Turn off scripted saber blade activation overrides. SetLightsaberPowered(GetFirstPC(), FALSE); SetLightsaberPowered(oJolee, FALSE); SetLightsaberPowered(oJuhani, FALSE); DelayCommand(0.5, SetLightsaberPowered(oBastila, FALSE)); DelayCommand(0.6, ActionResumeConversation()); }

I just checked and everything you need is in the Object Properties of the OdysseyBase of the model as I suggested above, the same as KMax. How you go about adding new anims though is something I can't help with, since I don't use Blender. I've already done the first. You can have a look at what I did with that if you want to expand on the idea - https://deadlystream.com/files/file/1736-movie-style-holograms-for-twisted-rancor-trio-puzzle/ The second one isn't really going to work. Since this involves the player, the only practical way to do it would be with a stunt animation, but those are fixed position (i.e. they are animated in the position you want them within the module the scene occurs in). Since you can pick up a Gizka anywhere inside the Hawk or on Yavin Station, it would be pretty jarring. The last one would need to be a stunt animation for the player at least, but in this case it would be fine since the scene takes place in a specific fixed position. Lynn herself could either use a stunt animation or the substitution trick, since she's a unique NPC you only see in that scene. The scripted call of animations does indeed use limited hardcoded values. In K1 it is the anims listed in nwscript.nss, which is only a subset of the available anims in the game. However in TSL you can call any anim via its animations.2da row ID. This makes animating cutscenes via scripting difficult in K1.

In KMax animations are defined in the model base, I would assume KBlender follows the same approach. That includes the name, length/keyframe range, SFX, supermodel, animation scale, etc. The Gizka hopping anim is just a standard walkcycle, so it doesn't move anywhere. Physical movement within the game is handled by scripted move commands. Before you go further, you should probably outline what exactly it is you're hoping to achieve. Chances are you're going to have to curb your ambitions, because what you can do with animations in either game is extremely limited. You can't add new general purpose animations (i.e. combat, conversation, etc.), only replace existing ones. There is some wiggle room within the existing framework, depending on the circumstances, substituting certain animations for others. For example, using the dance animation "slot" for something else. The only real true freedom you have is with stunt animations, but those are only used during cutscenes/conversations.

Changing the background music is scriptable. Turning it on, off, switching to a different track. You should be able to add animations in Blender, but I don't use it so I can't really tell you much about it. You'd be better off quizzing @seedhartha about it directly, assuming the readme doesn't cover it.

To your first question, you can use the cheat console to warp to any module, but certain mods might require specific circumstances regarding plot states/variables. There are some saves available in the download section that may prove useful for such cases. However, a critical factor is that certain game states, notably anything in the GIT, are stored in a save the first time you enter an area, so ideally for testing purposes you will want a save right before entering every module for the first time. It's rare that a single mod would require a full playthrough to test, unless it is an extremely large mod like a total conversion or other similarly expansive project (for example, K1CP or TSLRCM). But assuming you don't have appropriate saves to hand, then you could conceivably have to play a decent chunk of the game in order to test everything. You can often fudge what you need though by editing saves with KSE and/or manually via KGFF (e.g. changing globals, editing GITs, etc.). Regarding Blender, that's only a relatively recent development for KOTOR modding, so you won't find a lot of specific information about it. But what I can tell you is that with the advent of seedhartha's fork of KBlender you won't need MDLEdit or MDLOps, as it now imports and exports binary models directly. The ASCII workflow is only needed when using Max/GMax. Binary models go in the Override folder. Use SithCodec to strip fake headers or add them from/to audio. The underlying format is either an MP3 with a fake WAV header, a WAV with a fake MP3 header, or just an non-obscured WAV. Which it is depends on what specific type of audio it is (VO, music, SFX, etc.). As to the format, just take a vanilla example and copy whatever that is. As a general rule you don't edit the TLK exactly. TSLPatcher can only append new lines, it can't edit existing ones, so there's no practical method to distribute mods that edit the vanilla TLK lines without a hard overwrite of the TLK. If you want to know how to append, read TSLPatcher's included readme PDF which explains the process (and how to use it for all other major mod installation functions). Where audio goes depends on the type (and which game). VO goes in streamwaves (K1) / StreamVoice (TSL) in a sub-folder for the specific DLG inside the sub-folder for that module, except for global lines. Music goes in streammusic and SFX in streamsounds. LIP files are generated using the CSLU Toolkit and LipSync Editor. As to the how, here's an overview of the process. It doesn't work so hot for alien gobbledygook though. If you are talking about TSL's alignment gain stings, those are hardcoded. There was a mod released just the other day that tries to emulate that functionality for K1 - https://deadlystream.com/files/file/1956-k1-alignment-fancy-bits/