Is there a script that you can attach to a node on a dialog file that changes the .dlg-file? Let us say that I have two .dlg files. One is for the NPC when he still isn't recruited. When I press the dialog option that recruites him the dialog file will change. So there will be a totaly different dialog.
Is there a script that you can attach to a node on a dialog file that changes the .dlg-file? Let us say that I have two .dlg files. One is for the NPC when he still isn't recruited. When I press the dialog option that recruites him the dialog file will change. So there will be a totaly different dialog.
No, the only way to alter the default dialog file for an NPC is to modify their AI scripts, which usually is an overkill solution for such a thing. Usually it's enough to keep everything in the same dialog file, but put a conditional script on the entries so that some only will fire when recruited or not recruited.
This is usually how it works with the standard game NPCs. The Handmaiden for example uses the same dialog file when you first encounter her at Telos as she does when she has joined up with you.
But I want to change the dialog more than once.
For example:
-Hi.[NPC]
-Hello.[PC]
-Are you OK?[NPC]
-Yes. [PC] (Insert the script that I am looking for. It will change the dialog.
I start a dialog with the same NPC again
-Hello OK-man[NPC]
-Hi.[PC]
-Are you Ok.[NPC]
-Nope. [PC](Insert the same script again)
I walk away.
I start a dialog again.
-Hello anit-ok man. [NPC]
-Hi.[PC]
You get the point..
But I want to change the dialog more than once.
For example:
(snip)
You get the point..
That's pretty much a textbook example of what you use dialog conditional scripts for. A conditional script blocks out an entry or reply node in conversation, making the game move down to the next, unless the script returns TRUE.
So in the same DLG file you make different top-level entries for the various ways you want conversation to start with the NPC. On each entry you put a conditional script that checks if a variable is set.
Whenever you want a new dialog branch to be used you run an action script that changes the value of the variable that your conditional scripts are checking.
To use a somewhat modified variant of what you said above as a simple example, the DLG file could be laid out like this.
[ROOT]
[E1] Hi (conditional: st_checkbranch - P1: 0)
[R2] Hello
[E4] Are you OK?
[R3] Yes. (action: st_setbranch - P1: 1)
[E2] Hello again! (conditional: st_checkbranch - P1: 1)
[R4] Why hello there.
[E5] Are you still ok?
[R5] Indeed I am. (action: st_setbranch - P1: 2)
[E3] Go away kid, you bother me. (conditional: st_checkbranch - P1: 2)
[R6] You don't like when people talk to you repeatedly?
[E6] I love nothing more than answering your questions, truly.
[R7] Fine, be that way!
[R] are Reply nodes (PC speak), [E] are Entry nodes (NPC speak)
Here your dialog uses two scripts (see code below):
st_checkbranch - conditional script that checks if the variable has the value specified in the P1 parameter set.
st_setbranch - action script that sets the variable to the value specified in the P1 parameter.
Dialog trees are read from the top down, starting at the top [ROOT].
First it checks [E1] and sees if its conditional script returns TRUE. The first time the dialog is triggered this will be true, since the variable is unset (value 0). Thus this part of the conversation is run. The last node of that conversation branch runs the st_setbranch action script, which changes the value of the variable to 1.
The next time the dialog is initiated it checks [E1] again. This time however the value of the variable is not 0, so the entry is skipped. Next down is [E2], whose conditional script checks if the value is 1. Since it is (since we set it to 1 at the end of the first talk) this part of the conversation is run. Again, the last node of that conversation branch runs the st_setbranch action script, which changes the value of the variable to 2 this time.
You walk away, and talk to the NPC again. The dialog checks [E1], but the conditional script returns FALSE (since the variable value is 2 and not 0). Thus it moves down to [E2], but the conditional script here also returns FALSE (since the variable value is 2 and not 1). It moves on to [E3], where the conditional script returns TRUE (since we set the value to 2 at the end of the second chat). Thus this dialog branch is entered. The variable is not changed here at the end, causing this branch to be used if the player tries to talk to the NPC more times as well.
The two script files used in this example could look like:
st_checkbranch.nss:
int StartingConditional() {
return GetLocalNumber(OBJECT_SELF, 16) == GetScriptParameter(1);
}
st_setbranch.nss:
void main() {
SetLocalNumber(OBJECT_SELF, 16, GetScriptParameter(1));
}
(As usual they'd need to be compiled to NCS files, and have the name of the NCS files set in the Script# and Conditional# fields on the dialog as outlined above.)
I am making dialogs for k1. Where should I put the scripts? In the "fires when spoken" or "determines availabity"?
I am making dialogs for k1.
Then now would be a good time to despair. :crybaby:
Since KOTOR 1 does not support dialog parameters you'll have to make a separate script for each conditional check and for each set action. That could be a lot of scripts, depending on how complex your dialog is supposed to be. Fortunately they'll be mostly similar, you just have to specify the values to check for and set directly in the scripts instead of using GetScriptParameter(1).
Where should I put the scripts? In the "fires when spoken" or "determines availabity"?
If you use KOTOR Tool's dialog editor instead of tk102's DLG Editor then determines availabity should be the conditional script and fires when spoken should be the action script.
I use tk102's DLGeditor.
Then determines availabity should be the conditional script and fires when spoken should be the action script. :D
(So long since I did any KOTOR 1 dialog editing that I didn't remember that the labels changed depending on game mode in tk102's editor :))
I didn't remember that the labels changed depending on game mode in tk102's editor :)
Neither did I :o
About these two scripts:
int StartingConditional() { return GetLocalNumber(OBJECT_SELF, 16) == GetScriptParameter(1); }
void main() {
SetLocalNumber(OBJECT_SELF, 16, GetScriptParameter(1));
}
Will I have to change the number 1 to 2? And 2 to 3?
Because as you explained here Stoffe:
[ROOT]
[E1] Hi (conditional: st_checkbranch - P1: 0)
[R2] Hello
[E4] Are you OK?
[R3] Yes. (action: st_setbranch - P1: 1)
[E2] Hello again! (conditional: st_checkbranch - P1: 1)
[R4] Why hello there.
[E5] Are you still ok?
[R5] Indeed I am. (action: st_setbranch - P1: 2)
[E3] Go away kid, you bother me. (conditional: st_checkbranch - P1: 2)
[R6] You don't like when people talk to you repeatedly?
[E6] I love nothing more than answering your questions, truly.
[R7] Fine, be that way
The scripts changes variables. And how? Do I have to edit the scripts so they will look like this?:
int StartingConditional() { return GetLocalNumber(OBJECT_SELF, 16) == GetScriptParameter(0); }
void main() {
SetLocalNumber(OBJECT_SELF, 16, GetScriptParameter(1));
}
int StartingConditional() { return GetLocalNumber(OBJECT_SELF, 16) == GetScriptParameter(1); }
void main() {
SetLocalNumber(OBJECT_SELF, 16, GetScriptParameter(2));
}
And so on...
About these two scripts:
Will I have to change the number 1 to 2? And 2 to 3?
No, the number passed as parameter to the GetScriptParameter() function corresponds to the P1, P2, P3, P4 and P5 parameter fields present in K2:TSL dialog files. Thus GetScriptParameter(1) will return the value set in the P1 field.
The first script checks if the value stored in LocalNumber #16 is the same as what has been set in the P1 field. The second script sets the value of LocalNumber #16 to the value set in the P1 field.
This is used to enable which dialog branch is triggered. At the end of each dialog branch you set the number to the one required for the next dialog branch to become available.
So exactly... what will I have to do? Should I change anything in the scripts or should I just write in the script in the dialog and name it P1, P2, P3, P4 and P5?