Dialog editing tutorial
Mod note: Originally posted in this thread. ~M
I’m going to use my own, terribly written, dialogues as examples to introduce you to the wonderful world of dialogue editing and creation. Below is an overview of what you might see if you opened up a conversation in tk102’s dialogue editor. The way things look is entirely due to whether you have the mode set to KotOR or KotOR II. You can change the mode by clicking on “Mode” then selecting “Toggle Mode: KotOR” or “Toggle Mode: TSL.”
An overview of what you might see in K1 mode.
An overview of what you might see in K2 mode.
The system is simple. Each line you see is called a node. Red coloured nodes are nodes that the NPC will speak and blue ones are the player’s options. If the NPC speaks over multiple nodes a blue (continue) will be in between the nodes, this will be skipped over in the game, allowing the NPC to talk over many nodes before the player can next choose something to say. If (already listed) appears beside a node then it is a link to another node, a copy of it, essentially – these prevent you from having to type out multiple copies of the same line (much handier than you can possibly realise now). You can find the original by right clicking on it and selecting “Jump to original.” or by double-clicking the node ~tk
To add an NPC node simply press Ctrl+E or go to “Edit” and click “Add new entry.” To add a player reply node press Ctrl+R or go to “Edit” and click “Add new reply.” You should be able to type what you want the player to see in the large, white text box over to the right hand side of the screen.
Scripting and dialogues
Scripting can be confusing, especially to newcomers with no background in programming (heck, it still confuses me and I’ve been doing it for two years now). Unfortunately, it’s something you have to learn if you want to create more sophisticated mods for KotOR.
There are two types of scripts that can be attached to a KotOR dialogue conditional and action. A conditional script will return TRUE or FALSE. If the conditions are met then the node will be shown to the player (hurrah!) if they are not (boohoo) then the dialogue will drop down to the node beneath it. If there is no node beneath it then the game will exit the dialogue. In this way we can create dialogues with multiple openings, or even change the way an NPC talks to the player depending on the player’s actions.
If the condition for 1 is not met then the game will try 2. If that doesn’t work then it will go to 3 and so on. It is sometimes useful (for debugging purposes) to create a node right at the bottom with no conditions attached to it saying something like “I SHOULD NOT BE HERE.” This tells you that there is a fault in the checking of or setting of conditions and that nothing else is going wrong. In KotOR dialogue files there is space for just one conditional script; in TSL we have the added luxury of being able to use two. Also, in TSL, we have the “Not” tick-box. This means that if a script returns FALSE then the dialogue will read it as TRUE. For example, if you had a script that checked if the global number “000_FooBar_Talked” was set to 1 and you wanted to check if it was not 1 without creating another script you could just check this box!
Action scripts are a little more exciting but not a lot; not when compared to the prospect of finding a real, living gizka in your bathroom – though, admittedly, that may be a little freaky. These are used throughout the game to accomplish a wide variety of tasks ranging from turning the NPC hostile to giving the player the Awesome Lightsaber of +5 Wisdom. Suffice it to say: they’re useful. Again, with KotOR there is space for just one script but there are two fields in TSL.
I’m not going to go over the basics of scripting conditionals and actions in this post as it is already on the verge of becoming long enough to make people want to hang themselves after reading it – or during, of course.
Well… we’re finally here… writing the conversation. The first stage, and this may seem a little obvious but it’s where I went wrong when attempting to write my first conversation, is to open tk102’s editor and. Go to File --> New to open up a new dialogue. It should be devoid of anything save the root node which in tk’s editor appears as the file pathway or (until the dialogue is saved) “New Dialog.” Click on this wonderful root and add a new node (as we discussed above). Type what you will in there. The first line after the root is always an NPC line.
Now click on that entry and add in three responses using Ctrl+R as we discussed above. Every time you add an empty response you’ll have to click on the NPC line again because the editor will switch focus to the new line. Type whatever you wish to fill these lines.
We just spoke about the dialogue dropping down to the node below and we’re about to use it. Imagine the power at your fingertips! You may cackle evilly if you wish… just no wearing spandex and dressing up like Darth Malak, please. Click on our stylish root node and add a new entry as we discussed above and type something for the NPC to say the second time the player comes to speak to them and add in your beautifully crafted player responses.
Now… we’re going to attach some global scripts. These are standard game resources. We’re using them to check if the player has spoken to the NPC beforehand. If your dialogue if for KotOR then type “k_act_talktrue” in the “Script that fires when spoken” field on your first speaker node and then type “k_con_talkedto” in the “Script that determines availability” field. In TSL the principle is the same. Set conditional #1 to “c_talkedto” and set the script #1 field to “a_talktrue.” Any scripts that you ever place in these fields should not have the extension attached.
Creating links is another thing we touched on above. These are very useful… so much so that I could marry them if the state would allow it but alas… we’re a bit behind the times in these parts. To create a link simply copy a node and paste it elsewhere in the dialogue – simple as that!
Shockingly… that’s it for basic conversations – hope that wasn’t too soul destroying to read through.
Other interesting thingmobobs
Click on your root node and revealed to you will be an entirely new set of options – the fun just doesn’t stop, does it? The fields of interest here are mainly grouped in the area shown below:
Script that fires when conversation ends – As it says… this is the script to have the game execute when the dialogue ends
Ambient track – the name of a music file in the streammusic folder that you want to play over the dialogue (without the extension, as ever). It is, however, advisable to stop the area music via a script when using this feature.
Camera model – the name of the animated camera your dialogue will use.
Skippable – Please, unless you’re dealing with a plot essential cutscene, always check this. There is nothing more annoying than a pazaak player with an “unskippable” dialogue.
Animated Cut – Sets whether or not this is uses an animated camera – this must be checked to make use of the camera you specified in the “Camera model” field.
UnequipHItem – Unequip headgear from all NPCs for the duration of this dialogue, they will be added back later.
UnequipItems – Unequip all other items from NPCs for the duration of the dialogue. Again, they will be returned at the end of the conversation.
Apologies for the ridiculous size of this post... I just got a little carried away. I'm also not sure if any of this is of use to you but I was a little bored, you see.
Using local and global variables in TSL to check conditions
Which type you choose to use is generally up to you, but just tracking dialog stages of a single NPC is often best to set as either a local number variable, or a series of local boolean variables, on that NPC, since the info is only needed by that NPC thus reducing the amount of global data the game need to keep track of, and you won't have to modify any 2DA files for them to work.
For things like plot progress, quests and the like you usually use global variables, since those can be checked from anywhere and aren't associated with one particular NPC or object.
In TSL there are a number of ready-made scripts you can use to set and check both global and local variables in dialogs.
P1, P2 and String Param above refer to the input fields listed to the right of the script name field in tk102's DLG Editor.
Some local numbers and booleans are already used by generic scripts such as the Random Loot and AI scripts, and as such should be avoided for any objects of that type that have AI scripts/loot scripts. Here is a likely incomplete list of some locals already used:
|All times are GMT -4. The time now is 05:31 PM.|
Powered by vBulletin®
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
LFNetwork, LLC ©2002-2015 - All rights reserved.