16 replies to this topic

[Kulyok]

If you're a modder, and you've already coded your first NPC, your first romance, or your tenth mod, you won't find anything useful here, I'm afraid.

But if you're just starting with your idea of an NPC mod, this is going to be useful.

Why am I writing this? Because I think that coding in .d is a really, really tedious and ungrateful work, which is why I think that every beginning NPC/romance/quest writer should know how to do it. And because it's That Simple.

It is easy, it will save time for you, and, if you are creating your mod with a help of a coder(or via "How to do this?" threads in IE Modding Help/Modding Q&A/your own forum), for others, too.

And if you've got your whole romance or NPC coded in perfect .d, finding a coder will be much easier - most of the work is already done.

So,

Talks with the PC: lovetalks, friend talks and more.

Let's take an example talk and code it. It's a romantic talk with Valygar.

A beautiful night.
- Indeed. (to v5b.1)
- But not the most romantic setting, is it? (to v5b.1)
- Take my hand, and let us walk together under the stars. (to v5b.1)
- Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again... (to v5b.1)

(v5b.1)
Shh. Can you hear it? An owl hooting - there!
Here it flies off! A magnificent bird.
- It shouldn't be here, right? (to v5b.2)
- Perhaps it is someone's messenger. (to v5b.2)
- Valygar, why are we discussing birds? (to v5b.3)

(v5b.2)
Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.
- Valygar, I implore you: don't start about wizards. Not now. (to v5b.4)
- Or maybe they are courting. Just like we are. (to v5b.5)
- I wonder... (to v5b.last)

(v5b.3)
(Valygar looks at you in amazement, then laughs.)
Why indeed...  (to v5b.last)

(v5b.4)
Hmm? No, I was thinking of - never mind. (to v5b.last)

(v5b.5)
We are not, <CHARNAME>. We are... (to v5b.last)

(v5b.last)
You must be tired. Take my hand, and let's walk. Enough battles for today.

Rule 1: Every line should start with a tilde (~) and end with a tilde(~).

This is the most important rule ever. If you ever get an error during the mod's installation, it's probably this one.

Let's implement it.

~A beautiful night.~
- ~Indeed.~ (to v5b.1)
- ~But not the most romantic setting, is it?~ (to v5b.1)
- ~Take my hand, and let us walk together under the stars.~ (to v5b.1)
- ~Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again...~ (to v5b.1)

(v5b.1)
~Shh. Can you hear it? An owl hooting - there!~
~Here it flies off! A magnificent bird.~
- ~It shouldn't be here, right?~ (to v5b.2)
- ~Perhaps it is someone's messenger.~ (to v5b.2)
- ~Valygar, why are we discussing birds?~ (to v5b.3)

(v5b.2)
~Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.~
- ~Valygar, I implore you: don't start about wizards. Not now.~ (to v5b.4)
- ~Or maybe they are courting. Just like we are.~ (to v5b.5)
- ~I wonder...~ (to v5b.last)

(v5b.3)
~(Valygar looks at you in amazement, then laughs.)~
~Why indeed...~  (to v5b.last)

(v5b.4)
~Hmm? No, I was thinking of - never mind.~ (to v5b.last)

(v5b.5)
~We are not, <CHARNAME>. We are...~ (to v5b.last)

(v5b.last)
~You must be tired. Take my hand, and let's walk. Enough battles for today.~

Rule 2: Every line NPC says should start with a SAY.
If NPC says several lines, all NPC lines after the one starting with SAY should start with an equals sign (=).

Easy enough? Let's see how it's going to look:

SAY ~A beautiful night.~
- ~Indeed.~ (to v5b.1)
- ~But not the most romantic setting, is it?~ (to v5b.1)
- ~Take my hand, and let us walk together under the stars.~ (to v5b.1)
- ~Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again...~ (to v5b.1)

(v5b.1)
SAY ~Shh. Can you hear it? An owl hooting - there!~
= ~Here it flies off! A magnificent bird.~
- ~It shouldn't be here, right?~ (to v5b.2)
- ~Perhaps it is someone's messenger.~ (to v5b.2)
- ~Valygar, why are we discussing birds?~ (to v5b.3)

(v5b.2)
SAY ~Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.~
- ~Valygar, I implore you: don't start about wizards. Not now.~ (to v5b.4)
- ~Or maybe they are courting. Just like we are.~ (to v5b.5)
- ~I wonder...~ (to v5b.last)

(v5b.3)
SAY ~(Valygar looks at you in amazement, then laughs.)~
= ~Why indeed...~  (to v5b.last)

(v5b.4)
SAY ~Hmm? No, I was thinking of - never mind.~ (to v5b.last)

(v5b.5)
SAY ~We are not, <CHARNAME>. We are...~ (to v5b.last)

(v5b.last)
SAY ~You must be tired. Take my hand, and let's walk. Enough battles for today.~

Rule 3: PC replies should look this way: ++ ~Reply~ + NPC_answers_this_line

Note: if a line only works under a special condition(PC is an elf, for example), the form changes to
+ ~condition~ + ~Reply~ + NPC_answers_this_line, as in
+ ~Race(Player1,ELF)~ + ~Reply~ + NPC_answers_this_line

Implementing this one should be easy, if a bit tedious. Coding in .d right from the beginning has its advantages...

SAY ~A beautiful night.~
++ ~Indeed.~ + v5b.1
++ ~But not the most romantic setting, is it?~ + v5b.1
++ ~Take my hand, and let us walk together under the stars.~ + v5b.1
++ ~Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again...~ + v5b.1

(v5b.1)
SAY ~Shh. Can you hear it? An owl hooting - there!~
= ~Here it flies off! A magnificent bird.~
++ ~It shouldn't be here, right?~ + v5b.2
++ ~Perhaps it is someone's messenger.~ + v5b.2
++ ~Valygar, why are we discussing birds?~ + v5b.3

(v5b.2)
SAY ~Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.~
++ ~Valygar, I implore you: don't start about wizards. Not now.~ + v5b.4
++ ~Or maybe they are courting. Just like we are.~ + v5b.5
++ ~I wonder...~ + v5b.last

(v5b.3)
SAY ~(Valygar looks at you in amazement, then laughs.)~
= ~Why indeed...~  (to v5b.last)

(v5b.4)
SAY ~Hmm? No, I was thinking of - never mind.~ (to v5b.last)

(v5b.5)
SAY ~We are not, <CHARNAME>. We are...~ (to v5b.last)

(v5b.last)
SAY ~You must be tired. Take my hand, and let's walk. Enough battles for today.~

Rule 4: every block should have a unique name: IF ~~ block_name

"Unique" part is important, or you will get errors during the installation.

Easy? Easy.

IF ~~ v5b
SAY ~A beautiful night.~
++ ~Indeed.~ + v5b.1
++ ~But not the most romantic setting, is it?~ + v5b.1
++ ~Take my hand, and let us walk together under the stars.~ + v5b.1
++ ~Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again...~ + v5b.1

IF ~~ v5b.1
SAY ~Shh. Can you hear it? An owl hooting - there!~
= ~Here it flies off! A magnificent bird.~
++ ~It shouldn't be here, right?~ + v5b.2
++ ~Perhaps it is someone's messenger.~ + v5b.2
++ ~Valygar, why are we discussing birds?~ + v5b.3

IF ~~ v5b.2
SAY ~Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.~
++ ~Valygar, I implore you: don't start about wizards. Not now.~ + v5b.4
++ ~Or maybe they are courting. Just like we are.~ + v5b.5
++ ~I wonder...~ + v5b.last

IF ~~ v5b.3
SAY ~(Valygar looks at you in amazement, then laughs.)~
= ~Why indeed...~  (to v5b.last)

IF ~~ v5b.4
SAY ~Hmm? No, I was thinking of - never mind.~ (to v5b.last)

IF ~~ v5b.5
SAY ~We are not, <CHARNAME>. We are...~ (to v5b.last)

IF ~~ v5b.last
SAY ~You must be tired. Take my hand, and let's walk. Enough battles for today.~

Rule 5: every block without PC replies should have either an ending, or an order to move to the next NPC line right under the NPC line.
An ending:
IF ~~ EXIT
An order to move to the next NPC line:
IF ~~ + name_of_the_next_NPC_line

Does it sound scary? No, not really. We had

SAY ~Hmm? No, I was thinking of - never mind.~ (to v5b.last)

, and now we are going to have

SAY ~Hmm? No, I was thinking of - never mind.~
IF ~~ + v5b.last

, that's it.

So, our dialogue looks like this now:

IF ~~ v5b
SAY ~A beautiful night.~
++ ~Indeed.~ + v5b.1
++ ~But not the most romantic setting, is it?~ + v5b.1
++ ~Take my hand, and let us walk together under the stars.~ + v5b.1
++ ~Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again...~ + v5b.1

IF ~~ v5b.1
SAY ~Shh. Can you hear it? An owl hooting - there!~
= ~Here it flies off! A magnificent bird.~
++ ~It shouldn't be here, right?~ + v5b.2
++ ~Perhaps it is someone's messenger.~ + v5b.2
++ ~Valygar, why are we discussing birds?~ + v5b.3

IF ~~ v5b.2
SAY ~Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.~
++ ~Valygar, I implore you: don't start about wizards. Not now.~ + v5b.4
++ ~Or maybe they are courting. Just like we are.~ + v5b.5
++ ~I wonder...~ + v5b.last

IF ~~ v5b.3
SAY ~(Valygar looks at you in amazement, then laughs.)~
= ~Why indeed...~
IF ~~ + v5b.last

IF ~~ v5b.4
SAY ~Hmm? No, I was thinking of - never mind.~
IF ~~ + v5b.last

IF ~~ v5b.5
SAY ~We are not, <CHARNAME>. We are...~
IF ~~ + v5b.last

IF ~~ v5b.last
SAY ~You must be tired. Take my hand, and let's walk. Enough battles for today.~
IF ~~ EXIT

Rule 6, final: Every block, with replies or without, should have an END.

This one is just a quick copy and paste:

IF ~~ v5b
SAY ~A beautiful night.~
++ ~Indeed.~ + v5b.1
++ ~But not the most romantic setting, is it?~ + v5b.1
++ ~Take my hand, and let us walk together under the stars.~ + v5b.1
++ ~Uh-huh. And a very quiet one. Damn, now I have to wipe my weapon again...~ + v5b.1
END

IF ~~ v5b.1
SAY ~Shh. Can you hear it? An owl hooting - there!~
= ~Here it flies off! A magnificent bird.~
++ ~It shouldn't be here, right?~ + v5b.2
++ ~Perhaps it is someone's messenger.~ + v5b.2
++ ~Valygar, why are we discussing birds?~ + v5b.3
END

IF ~~ v5b.2
SAY ~Owls are clever birds. It may be carrying messages... look, another one! A wizard must be living nearby.~
++ ~Valygar, I implore you: don't start about wizards. Not now.~ + v5b.4
++ ~Or maybe they are courting. Just like we are.~ + v5b.5
++ ~I wonder...~ + v5b.last
END

IF ~~ v5b.3
SAY ~(Valygar looks at you in amazement, then laughs.)~
= ~Why indeed...~
IF ~~ + v5b.last
END

IF ~~ v5b.4
SAY ~Hmm? No, I was thinking of - never mind.~
IF ~~ + v5b.last
END

IF ~~ v5b.5
SAY ~We are not, <CHARNAME>. We are...~
IF ~~ + v5b.last
END

IF ~~ v5b.last
SAY ~You must be tired. Take my hand, and let's walk. Enough battles for today.~
IF ~~ EXIT
END

That's it! Coded.

Note that there is still one thing to do - setting the conditions for this lovetalk. To understand that, you'll have to read more on scripting in .baf, and how scripts work. If you want, you can start with:

1) A Beginner's Guide to NPC creation with WeiDU, and its expansion: How to make an NPC if you are a NOOB.

2) The road to banter - NPC-NPC dialogue, conditions, and more.

3) How to ensure your banters run when you want them to - that's scripting, quick and dirty.

(Or ask me or someone else to write another tutorial. AFTER you've coded your .d file, that is. )


Bottom line: rules to remember.

Rule 1: Every line should start with a tilde (~) and end with a tilde(~).
Rule 2: Every line NPC says should start with a SAY.
If NPC says several lines, all NPC lines after the one starting with SAY should start with an equals sign (=).
Rule 3: PC replies should look this way: ++ ~Reply~ + NPC_answers_this_line
Rule 4: every block should have a unique name: IF ~~ block_name
Rule 5: every block without PC replies should have either an ending, or an order to move to the next NPC line right under the NPC line.
An ending:
IF ~~ EXIT
An order to move to the next NPC line:
IF ~~ + name_of_the_next_NPC_line
Rule 6, final: Every block, with replies or without, should have an END.


(And, yes, when I saw Weidu readme and some of the more advanced tutorials for the first time, I panicked, too, especially after I saw the "Don't panic!" note. My first piece of .d code for Branwen romance was created via taking constant peeks at jastey's work - Ajantis romance, in that case. Do not be afraid to borrow code - just bring in your own ideas.)

Edited by Kulyok, 22 March 2008 - 04:13 AM.

[Kaeloree]

Thank you.

Thank you.

Thank you.

[SConrad]

Good work.

[Kulyok]

Thanks! I'm just saving myself time, really: it's time to start assemble Romantic Encounters, version 3, and having everything in .d from the start helps a lot.

[Alatariel]

I have all of that covered, however, if you ever feel like expanding this tutorial, I would love to see something on adding conditions to replies/outcomes/dialogues/banters. I have some problems here, as doing it all via globals would create far to many of them.. And if I am correct that may slow the game? Don't look at me like that. I am completely blue...er, green.

[Tieflingz]

I have to be honest

After reading tens and hundreds (Okay not hundreds, I exaggerated it), this is perhaps the most understandable tutorial for a newly born modder!! Step by step so that we could eventually understand, go back, and learn the concepts!

Fantastic Tutorial

[Alonso]

I'm trying to use the tutorials in this site to learn the very basics of IE modding. Can you explain what the example talk is about? Is it a file you create as a base for the actual mod or is it something else? What are those funny letters and numbers in parenthesis (to v5b.1)?

[jastey]

The dialogue will be inside a file which is a textfile (ANSI) with the extention ".d". This file will be inside the mod folder and will be compiled upon installation of the mod.

(Side info: Inside a d-file, there can be more dialogues than one. Because inside the d the dialogue-name ("dlg") are specified. Unlike a baf-file for a script, where you need one baf-file per script.)

 

I'll take the end result and explain the content there. You mentioned v5b.1, that's a name of a so called dialogue state. Every dialogue state consist of a line of the NPC first, and then either PC reply options or other so called "transactions", i.e. actions that will be performed after the NPC line when the player clikcs on "CONTINUE".

 

IF ~~ v5b.1 //this is the conditions for which this state is called: NONE, because inside the ~~ there is no trigger. This means, that this state cannot be called by a script, but only linked to inside a dialogue. "v5b.1" is the name of this dialogue state so WeiDU knows how to link the states when compiling this d-file upon installation.
SAY ~Shh. Can you hear it? An owl hooting - there!~ //this is the line the NPC is speaking. It will be displayed in a dialogue box. Because there is a second line following, the player needs to click "CONTINUE" after this one.
= ~Here it flies off! A magnificent bird.~ //this is a second line of the same NPC. The player will see it with the reply options beneath:
++ ~It shouldn't be here, right?~ + v5b.2 //reply option number 0: will lead to NPC line of dialogue state "v5b.2" <-- first reply option is counted as "0" like machines do, that's how weidu counts so we have to do it, too.
++ ~Perhaps it is someone's messenger.~ + v5b.2 //reply option number 1: will also lead to NPC line of dialogue state "v5b.2"
++ ~Valygar, why are we discussing birds?~ + v5b.3 //reply option number 2: will lead to NPC line of dialogue state "v5b.3"
END //END marks the end of this dialogue state and is compulsive syntax

[Alonso]

Thank you, @jastey, that was so helpful . Some questions:

 

What is the format of dialogue state names?

 

What language is this? I think I read somewhere that IE scripts are based on a funny scripting language developed in a Brazilian university.

 

this is the conditions for which this state is called

 

What conditions can be used to call a dialogue state? What is the purpose of calling a dialogue state?

 

either PC reply options or other so called "transactions", i.e. actions that will be performed after the NPC line when the player clikcs on "CONTINUE".

 

What kinds of transactions exist?

Edited by Alonso, 10 May 2019 - 10:08 PM.

[jastey]

What is the format of dialogue state names?

Do you mean why for the tutorial the name "v5b.1" was chosen? Basically, inside the d-file it is whatever you want to name it so you can read your dialogue comprehensibly. So, it's any name+number+symbol combination you want to use to keep track of your states and flow of dialogues. Important: no space inside the name. I name the whole dialogue something I can see which dialogue it is, say "first_meeting" for the greetings dialogue. Then the following states that still belong to this dialogue (because you have some chat options with the NPC) would be first_meeting_01, first_meeting_02, etc.

Note: upon installation, weidu will transform these state names to numbers, always. This is also what you get if you decompile a dlg: then you get a d-file where all states have numbers, starting with "0" for the first. The reason we use state names instead of numbers is that with names, you do not accidentally replace a number inside the dlg - in case that number might already exist. In fact, you don't have to care about numbers, and how many might already be in that NPC's dlg etcpp at all. WeiDU will apply numbers for your dialogue states appropriately.

 

 

What language is this?

Öhm... weidu? It's a scripting language, and quite similar to common programming languages. I have to admit I don't know which language it is most similar to.

 

 

What conditions can be used to call a dialogue state?

Usually, it would be the following scenario: something in the game happened. Or a timer run out. Now your NPC should react by starting a dialogue. So, you have a script block in his script which sets a variable, let's call it "Global("xxxNPCReactionY","GLOBAL",1)".

The engine then searches through the appropriate dlg-file of that NPC top to bottom. And what it expects to find is a dialogue state with the trigger "Global("xxxNPCReactionY","GLOBAL",1)", for example:

 

IF ~Global("xxxNPCReactionY","GLOBAL",1)~ THEN reaction_y

SAY ~blabla!~

IF ~~ THEN DO ~SetGlobal("xxxNPCReactionY","GLOBAL",2)~ EXIT //closes the variable

END

 

Alternative: you want the NPC to have a valid dialogue if clicked upon. (Either for quest characters or for an NPC "player initiated dialogue", PID).

 

For NPC PID, the "always true" trigger is "IsGabber (Player1)", meaning "it is the HC talking to me!". For a quest character, it is either True() with is always true, or something like NumTimesTalkedTo(0) which means "true if the quest character is talked to the first time".

 

For scripts, there is a lot more triggers as listed here. For dialogues, it is useful to put all other relevant triggers inside the script and use one specific variable inside the dialogue to trigger it.

 

 

What kinds of transactions exist?

Basically anything from here.

 

Taking a random dialogue (ANOMENJ.dlg in this case), here are some examples:

 

 IF ~~ THEN EXIT

//no transaction. Dialogue just ends.

 

  IF ~~ THEN REPLY #6380 /* ~You have a point, Anomen. I will hear this man out.~ */ EXTERN ~GARREN~ 3

//after this reply line, Garren Windspear will say his dialogue state 3.

 

  IF ~~ THEN DO ~AddexperienceParty(10500)~ EXTERN ~COR~ 15

//following actions: Party gets 10500 experience, and Anomen's father will speak his dialogue state 15.

 

  IF ~~ THEN DO ~SetGlobal("AnomenDecide","GLOBAL",3)
StartCutSceneMode()
StartCutScene("Cut10b")

//following actions: a global variable "AnomenDecide" is set to "3";

a cutscene is started, which is inside the script file Cut10b.bcs

  IF ~!IsValidForPartyDialog("Keldorn")
!IsValidForPartyDialog("Nalia")~ THEN EXIT
  IF ~IsValidForPartyDialog("Keldorn")~ THEN EXTERN ~KELDORJ~ 94
  IF ~!IsValidForPartyDialog("Keldorn")
IsValidForPartyDialog("Nalia")~ THEN EXTERN ~NALIAJ~ 145

//If Nalia is able talk (is in party, is not stunned / muted/ dead), Nalia will say her dialogue state 145.

If Nalia is not able to talk but Keldorn is, then Keldorn will say his dialogue state 94.

If neither Nalia nor Keldorn are able to talk, the dialogue will end.

 

Note: inside the dialogues, the transactions are processed bottom to top, so the last one is executed first.

(Note: if you want several NPCs to speak one after the other, there is a more elegant way to code it than using EXTERN and jumping from one dialogue file to another.)

Edited by jastey, 11 May 2019 - 12:40 AM.

[The Imp]

What kinds of transactions exist?

Well, anything between one that does literally nothing ... to the kind that destroyes the entire imaginary game world.

 

What language is this? I think I read somewhere that IE scripts are based on a funny scripting language developed in a Brazilian university.

*It's Infinity Engine script language. Really? Well, the bigger part of it is C, but correct, yes. Here's a link to the fan/modder created file format list used in the engine. And yes, there's a reference to this...

 

All versions of the Infinity Engine, except that used in Planescape: Torment, make some internal of the Lua programming language, as developed by TeCGraf at the Pontifical Catholic University of Rio de Janeiro in Brazil. In the Infinity Engine, LUA is primarily used for the cheats/debugging console. The debug console actually allows complete LUA programs to be entered and run, though these programs can only have a very limited affect on the game and the engine. The LUA documentation is available online, though knowledge of LUA is of limited use in IE modding. It should be mentionned, that unlike other engines where LUA is used, the Infinity Engine AI scripts have nothing to do with LUA.

 

But did you actually read that, then you understand that it's, used to... from Lua link:

Nowadays, many programs are written in two different languages: one for writing a powerful “virtual machine”, and another for writing single programs for this machine. Lua is a language designed specifically for the latter task. It is small: as already noted, the whole library is around six thousand lines of ANSI C. It is portable: Lua is being used in platforms ranging from PC-DOS to CRAY. It has a simple syntax and a simple semantics. And it is flexible.

.. make the use of tables. And faciliate the use of the Console.

 

*Funny thing, ask today how many people made any single object in your vicinity, and the answer lies somewhere in the ten billion. Yes, even the trees. And yes more than people alive today. How, the intergated sociaty was here before any of the people alive, so the monitary system, language, trade, goods and tools weren't created by a one man/woman, but the whole fucking lot.

Edited by The Imp, 11 May 2019 - 12:53 AM.

[Alonso]

Thank you for all the effort you're putting into helping with this.

What is the format of dialogue state names?

Do you mean why for the tutorial the name "v5b.1" was chosen? Basically, inside the d-file it is whatever you want to name it so you can read your dialogue comprehensibly. So, it's any name+number+symbol combination you want to use to keep track of your states and flow of dialogues. Important: no space inside the name. I name the whole dialogue something I can see which dialogue it is, say "first_meeting" for the greetings dialogue. Then the following states that still belong to this dialogue (because you have some chat options with the NPC) would be first_meeting_01, first_meeting_02, etc.

OK, but why use a funny name like v5b.1 when you could use something like first_meeting_01? That "v5b.1" sounds like an important format that he's using for something...
 

you have a script block in his script which sets a variable, let's call it "Global("xxxNPCReactionY","GLOBAL",1)". The engine then searches through the appropriate dlg-file of that NPC top to bottom. And what it expects to find is a dialogue state with the trigger "Global("xxxNPCReactionY","GLOBAL",1)"

Does it mean that every time you change the value of a variable in an NPC script a dialogue state is called?
 

For NPC PID, the "always true" trigger is "IsGabber (Player1)", meaning "it is the HC talking to me!".

What is an "always true" trigger?
 

What kinds of transactions exist?

Basically anything from here.

But you said that transactions come after the CONTINUE button. One of the actions in that page is, for instance, attacking. But attacking cannot come after the Continue button, because after the Continue button there is always another dialogue part, and it's not possible to attack while a dialogue is on. Attacking can only come after the End dialogue button.
 
Back to the tutorial itself, what's the meaning of all the text colours?
 

Rule 1: Every line should start with a tilde (~) and end with a tilde(~).

Not a single line in the dialogue state we've been discussing starts with a tilde.
 

Every line NPC says should start with a SAY.

This is the opposite of what he said in the previous paragraph.
 

If NPC says several lines, all NPC lines after the one starting with SAY should start with an equals sign (=).

And this is the opposite of the two things he said before.

I think that I can guess what he means, but it looks like he's actually saying the opposite of what he means. Which feels quite confusing, especially for beginners.
 

Rule 3: PC replies should look this way: ++ ~Reply~ + NPC_answers_this_line

What is NPC_answers_this_line?
 

Note: if a line only works under a special condition

What does it mean that "a line only works under a special condition"?

Edited by Alonso, 12 May 2019 - 08:55 PM.

[jastey]

but why use a funny name like v5b.1 when you could use something like first_meeting_01?

Personal preferences. Maybe it's the 5th NPC talk, and b because it's for romance, while 5a would be for friendship track, and 1,2,3 because that's the different reply options. Or something like this. Maybe just to show that you can use a mixture of letters and numbers.

 

 

Does it mean that every time you change the value of a variable in an NPC script a dialogue state is called?

No, that was phrased unclearly. A dialogue is only triggered if you explicitely script it * e.g. by StartDialogNoSet("Player1"). But in the same script block you set a unique variable, and this variable should be in the dialogue state's trigger so the engine knows it should pick this one.

 

 

* Except for "banter" called from a specific banter script which for original NPCs is called Bxxx.dlg. This is called by the engine randomly, and therefore needs other triggers than what I am writing here.

 

 

What is an "always true" trigger?

Always true means there is nothing you can do to change this. "True()" is always true. If you put True() in your dialogue state's trigger, it will be chosen by the engine every time it is checked.

"IsGabber(Player1)" is not a real always true trigger, because you could just chose another NPC out of the group for talking and it wouldn't be Player1 any more. But there is nothing you can do to prevent IsGabber(Player1) (without adding other triggers) to give true if it is Player1 who is doing the talking (Player1 is always the PC, not related to the party slot).

Whereas for a variable, you could just increment it by 1 - and it will no longer trigger the dialogue.

 

 

But you said that transactions come after the CONTINUE button. One of the actions in that page is, for instance, attacking. But attacking cannot come after the Continue button, because after the Continue button there is always another dialogue part, and it's not possible to attack while a dialogue is on. Attacking can only come after the End dialogue button.

Yes, you are right, I should have written that if the dialogue ends ("EXIT"), it's no longer a CONTINUE button but the END DIALOGUE button. If there is an attack command somewhere in teh middle of a dialogue for a quest character, it will be executed after the dialogue is finished - just because the dialogue is paused. The actual execution depends on the game (EE is faster than the old engine) and probably your computer settings. My experience is: if you set a variable inside a dialogue, it will take two NPC lines until you can use this variable inside the same dialogue (e.g. for disabling reply options etc.). For EE, there are ways to make it faster.

 

 

Back to the tutorial itself, what's the meaning of all the text colours?

Honestly speaking, the colors seem to be something the forum software does by itself if you use the CODE tags. It doesn't make any sense to me, tbh.

 

More to follow.

[jastey]

Rule 1: Every line should start with a tilde (~) and end with a tilde(~).

Not a single line in the dialogue state we've been discussing starts with a tilde.
 

Every line NPC says should start with a SAY.

This is the opposite of what he said in the previous paragraph.
 

If NPC says several lines, all NPC lines after the one starting with SAY should start with an equals sign (=).

And this is the opposite of the two things he said before.

I think that I can guess what he means, but it looks like he's actually saying the opposite of what he means. Which feels quite confusing, especially for beginners.

You have to see these rules with regard to the steps she is posting them in. The ~~ tildas refer to the actual text: all text needs to be inside two tildas. "Text" being what the NPC / HC will say, i.e. what is shown in the game for the player to read. If you forget a tilde, weidu will give some parsing error upon installation of your mod. A missing tilde was my first coding error and it took me 2 hours to actually see it.
If you write an NPC line, then there is a SAY (in comparison to the HC reply options, where there is no SAY.)
And if you just want to let your NPC say several lines one after the other, you do not have to jump from one dialogue state to another, but can just use the shortcut and add a new line with "= SAY", which is much easier.
Kulyok postualted the rules depending on the tutorial's steps she is showing in the examples. That's why they sound contradictory if you read them all together at the end.

Rule 3: PC replies should look this way: ++ ~Reply~ + NPC_answers_this_line

What is NPC_answers_this_line?

The state name of the dialogue state this reply will go to.
 

Note: if a line only works under a special condition

What does it mean that "a line only works under a special condition"?

It means it will only be shown in the game to the player if the condition is true for this player in this game. For example, if you add a race-specific reply options for an elf PC, it would not show if this player uses a human PC.

[Alonso]

I wanted to use this tutorial to learn some basics of IE modding, but this is a very complex topic (not for beginners in my opinion) and it's taking us a lot of  effort to clarify the concepts discussed here. I have a lot of mod ideas, but I don't think that these concepts are helpful for the kind of mods I want to create. So I think it's better to leave this area for now and focus on learning the concepts that are relevant for my mod ideas. Maybe I can come back to this tutorial when I have more experience with modding.

 

Thank you again for all your answers and clarifications.