So let’s get started!
Planning Your Quest
The first step to doing any quest creation is writing out an outline of the quest. For most of you working from the claims browser, these outlines will be provided for you. Even so, it’s helpful to break it down into steps so that you know what needs to be implemented.

In general, quests follow a very simple format:
1) The player finds out about the quest and talks to the quest-giver.
2) The player does whatever the quest-giver wants them to do, such as find an item or kill a monster.
3) The player then returns for their reward, usually given to them by the original quest-giver.

Obviously, these steps can be added to, such as the player having to find more than one item, or the quest-giver giving them additional tasks, or the player having to find out about the quest by doing other quests first. This I will cover later in (link).

For the purposes of the tutorial, I’ve planned out a very simple quest called Kevaar Finds a Shiny. It goes like this:

1) The player speaks with Kevaar, who talks to them about a ring he found. The player offers to find the ring’s original owner.
2) The player speaks to characters around town about the ring. The player finds out that the ring belongs to Fargoth, and gives it to them.
3) The player returns to Kevaar for their reward for returning the ring.

Though this quest design could be expanded to add more twists in the plot or additional ways for the player to finish the quest, it is enough to start crafting my quest.

The Quest Journal
The first step to creating your quest in the Construction Set is creating the Quest Journal entries for it. (Well, actually the first step is opening up the Construction Set, but we’re assuming you already know how to do that and won’t be covering it in this guide!)

You first navigate to the Dialogue Window. This is a little icon near the top of your screen that looks like a speech bubble. Click it.

(picture of dialogue icon)

This opens up the dialogue window. In the default view, here you can see all the dialogue ever written into the game. To get to the Quest Journal, you’ll want to navigate over to the tab that says Journal.

(picture of dialogue window with mouse over tabs)

Here you will see a list of all quests that have been implemented into the game. To create your own, right click on any quest title and click New.  (It doesn’t matter which quest you do this to, as you won’t be changing it by doing this.) Type in an ID for your quest. Note that changing the ID gets tricky later on, so you’ll want to make this something short, unique, and identifiable to you at a glance. I choose to give my quest the ID "TR_KevaarShiny".

ProTip: Adding the same prefix to all your mod's IDs is good modder etiquette, as now anyone who opens up your mod in the CS knows exactly what you contributed to the game world. It also serves the purpose that you yourself can quickly navigate to your own work! TR maintains this philosophy in that we prefer you use the TR_m#_AB_ShortQuestName format when doing TR quests, where # is the number of the map the quest can be found in (m0, m1, m3, etc), AB is an abbreviation of either the city or the faction in which the quest can be found (TG for Thieve's Guild, OE for Old Ebonheart, etc), ShortQuestName is your quest title shortened to just a few words, and TR always goes at the beginning.

The next thing you will need to do is create the title of the quest as it will appear in your ingame journal. You can add this at any time, but since I already know my title, I’ll do that now. First I’m going to right-click in the Info/Response window, and select New. Then I’m going to navigate down to the text box and type in my title, capitalized correctly. As this is the Quest Name, I am then going to click on the “Quest Name” checkbox, so that the game doesn’t inadvertently give me a journal entry that says nothing but Kevaar Finds A Shiny. Because that would be strange. Unless you’re Kevaar.

(screenshot of my purdy title)

ProTip: If I were making a quest for a faction such as the Fighter's Guild, I would want to be sure to add this to the beginning of my Quest Name, followed by a colon. This is to keep my quests consistent with the vanilla game's conventions. Eg: "Fighters Guild: No Sin Goes Unpunished" instead of just "No Sin Goes Unpunished"

Next I’m going to start making the rest of my journal entries. These will appear in the ingame journal as the player plays through my quest. These entries also help you, the backend writer, to organize your quest in logical steps. I’m going to be making a simple quest, so I’m going to add just three entries to start with.

The first entry should be what appears once the player stumbles upon your quest for the first time. Sometimes you will have multiples of these depending on how many ways the player can find your quest, but I will just have the one. First I click on the Info/Response tab and click New, just like when I made my quest title. In the textbox, this time I will be typing out exactly what I want to appear in the journal entry itself. (The game engine will automatically handle adding a date to the entry). Using the logic of Topic-Based Dialogue, I want to write blandly, so that conceivably any kind of character could be writing this.

(quest entry 1 screenshot)

I also want to add an Index number to this entry. This is used later on for identifying what stage of the quest the player is on. Since this is the first entry, I will call it 10. I like to use multiples of 10 just in case I forget an entry and need to go back and add others in between. Entries should be in the order you expect the player to come across them, for it makes your life easier later on down the road.

If I haven’t already, I am going to SAVE my mod file!

Next I will add my second entry. For the purposes of my simple quest, this will be the entry that shows up when the player has returned the shiny to its owner successfully but has yet to tell Kevaar. I will call it 50. If I were writing a mystery quest or a quest with multiple steps, I might realize later I need other entries that happen between 10 and 50, which is why I chose such a big gap.

(quest entry 50 screenshot)

Finally, I need to write an entry for once I have returned to Kevaar and he has given me a reward for completing his quest. I am going to call this entry 70. Since I don’t want this quest hanging around forever in the player’s journal, I will also check the Finished box so that the quest no longer appears once the player has finished it. I should have entries like these in the quest journal when I am done:

Journal Index 0
Quest Name checked
"Kevar Finds a Shiny"

Journal Index 10
"Kevaar found an abandoned ring. He's asked me to find its owner."

Journal Index 50
"Fargoth says he is the owner of the ring Kevaar found. I should make sure Kevaar knows this."

Journal Index 70
Finished checked
"Kevaar thanked me for finding the owner of the ring and assures me he will give it to Fargoth."

And that’s all I have to do for my simple quest journal! For tips and tricks to using more complicated journal entries, click here (link). If you haven’t already, SAVE your mod file!

Next, we will be handling creating all the objects needed for the quest.

Creating Objects
After creating my quest journal, the next thing I want to do is make sure I have all the objects I need for the quest.  (An object is any item or character the player may interact with through the course of the quest.) The easiest way to do this is to go back to my original outline. For instance, in Kevaar Finds a Shiny, my quest is planned to go like this:

1) The player speaks with Kevaar, who talks to them about a ring he found. The player offers to find the ring’s original owner.
2) The player speaks to characters around town about the ring. The player finds out that the ring belongs to Fargoth, and gives it to them.
3) The player returns to Kevaar for their reward for returning the ring.

 I see that I need three unique objects for this quest: a Kevaar NPC, a Fargoth NPC, and a ring. When I go into the Construction Set, I see that while Fargoth already exists, neither Kevaar or a unique quest ring do. I will need to create them. (When working with claims, sometimes the NPCs and quest items already exist, and sometimes they don’t, so you will need to check!)

Creating Kevaar
I will first create my Kevaar NPC. I first navigate to the NPCs tab, right click within it, and click “New.” A window will open with lots of values to fill in, which I will explain briefly here.

ID
First, the ID that I call my NPC for use in scripting. This is a unique identifier for the NPC and is read by the game engine only; it never appears ingame. You can make this anything you want, but while writing for TR, you should follow our naming convention, which goes: TR_m#_Q_FirstName_LastName, where # is the map number the NPC can be found in, and FirstName_LastName is the name of the NPC with underscores instead of spaces. In this case, I would call Kevaar "TR_m0_Q_Kevaar".

Name
The next part is the character’s name as it appear to players. With a few notable exceptions, all characters in TES3 have both a first name and last name, and no title. I notice that my quest design has failed to give Kevaar a last name, so I will come up with one now. I’ll call him Kevaar Ezran.

Script
For now, I will ignore this, but it comes in handy later when telling the game engine to track the status of certain NPCs or giving them special abilities.

Race
This governs what race the NPC will be. I want Kevaar to be a Dunmer, and so select Dark Elf.

Female
This checkbox makes the NPC into a female. Kevaar is a male, so I will leave this unchecked.

Class
The NPC’s class governs what skills they’re good at, what spells they have access to, and in some cases, generic dialogue available to them. Classes also include service packages such as Training and merchant services, so I will want to test my choice out ingame to make sure I am not inadvertently letting people barter for Kevaar's inventory! In my simple quest, I imagine Kevaar to be a simple peasant, and so give him the class of Commoner.

Level
This governs how strong the character is. Since players will be meeting Kevaar in a low level area and he is not intended to be a fighter, I will set his level to 5.

Faction and Rank
Unlike the player, NPCs can only belong to one faction at a time. This classification typically effects an NPC’s disposition to the player, some generic dialogue, and some universal questlines. As I want Kevaar to be friendly to thief characters and don’t mind him giving thiefly advice, I will make him a Wet Ear in the Thieves Guild.

Essential
I will be leaving this one alone. Unlike later games, in TES3, all being essential does is tell the player they broke the main quest if they kill this NPC. It doesn’t make them immune to death.

Corpses Persist
If killed, this governs if the NPC’s body sticks around. This is useful for quests where you need to loot a unique item from the body, as it keeps the body from disappearing if the player inadvertently leaves the area before obtaining the quest item. As I don’t foresee this occurring in my quest, I will leave this checkbox alone.

ProTip: "Play Dead, Fido!"
Sometimes you will want to write a quest where the NPC shows up dead when the player first encounters them. Doing this makes use of the NPC's Health statistic and the Corpses Persist Option. To make the NPC appear and act like a corpse (including being able to be looted), you set their base Health to 0 in their statistics menu. Then you check the Corpses Persist box, so that there isn't a split second of the death animation playing whenever the player comes across the NPC, and new items aren't generated in their inventory if the player comes back to them at a later date.

Respawn
This effects whether the NPC can respawn after being killed. Since Kevaar is unique and afaik doesn’t have nine lives, we won’t check this box.

Attributes and Skills
These are set automatically when you choose a Class and Level. However, if I wanted to change one of these manually, I could do so by unchecking “Auto Calculate Stats” and editting them to my tastes.

ProTip:
One case in which you might want to edit an NPC's skills is when you are trying to put a specific armor set on them. NPCs are (somewhat) intelligent, in that they will first try to equip armor that matches their best armor skill. So if I were to give Kevaar an Ebony Cuirass and a Netch Leather Cuirass and his Light Armor skill is higher than his Heavy Armor skill, he may still choose to wear the Netch Leather Cuirass, even though it's a worse piece of equipment.

Head and Hair Listing
Unfortunately there is no easy way to preview these within the CS itself, and you must either pick these by trial and error, or by referring to a head and hair guide like the one available here: http://mw.modhistory.com/download-106-14751. I chose b_n_dark elf_m_head_07 and b_n_dark elf_m_hair_21 for Kevaar, but if you are modding for Tamriel Rebuilt, this is a great opportunity to make use of some of the new meshes available!

Items
This governs what is found in a NPC’s inventory when slain or pickpocketed, and what the NPC wears. Note that the Morrowind engine automatically equips the best items for a NPC's skill set, which then makes it impossible for those items to be pickpocketed. For instance, if I wanted Kevaar to have access to a pair of Medium Armor boots for the player to steal, I would have to make sure the boots he wears are either more valuable, or belong to a skill he is better in than the boots I want to be pickpocketed.

For the purposes of my quest, all I want to do is make sure Kevaar has some clothes on. I will not put the quest ring in his inventory, because giving this to the player will be handled by a script later on, and giving it to him now would cause duplicates.

Spells
These are automatically chosen dictated by the character’s Class and Race. But if I wanted to add some special spells to the NPC, I could do so here after unchecking the "Auto Calculate Stats" box.

After setting all these attributes to my liking, I will click the Save button. I will also save my mod file!

Placing Kevaar: Keep Him From Wandering Off!
A player can’t talk to an NPC that isn’t in the game world! I will also want to pick a spot for to put my new Kevaar NPC. Since placing objects is already handled in other tutorials (link), I will only draw attention here to the Wander mechanic for NPCs.

Wander is a script automatically assigned to NPCs that makes them randomly walk about on their own. Most NPCs in exteriors will have this, while most NPCs in interiors won’t, as they have a tendency to climb on tables or get stuck behind crates otherwise. I want to put Kevaar in Seyda Neen’s Lighthouse, an interior, so I’ll want to make sure he doesn’t Wander.

To do this, I’ll want to open up his NPC window, and click on AI. In the list of AI Packages there should be one called Wander. I will double-click this, and set the distance to 0. I will then click Save in each window to save the change. Now Kevaar will stay put and not wander off.

Creating the Ring
Next, I want to create the ring. This is most easily done by finding an existing ring and tweaking it to my liking rather than making an entirely new one. First I will go to the Clothing tab and find a ring that seems close to what I want my quest ring to be. I’ve picked ring_keley. To create my ring from this one, I right-click on ring_keley, and click “Edit”. I then give this ring a new ID and click Save. I want to be very careful to tell the editor to create a New Object in the dialogue window that pops up, or else I will replace the existing version with my quest version, and thereby may break both my quest and any others that use ring_keley!

After saving my quest ring under a new ID, I can tweak the quest ring to my liking, such as changing the enchantment or the value. Since I don’t intend the player to be keeping this ring, I’m going to keep the value and enchantment trivial.

Pro Tip: Since enchanting an item changes the ID, a good way to keep players from accidentally breaking quests is to give the quest items an enchantment.

Creating a Reward?
Finally, I also want to give some consideration to what reward to give to the player once they have completed the quest. While most quest designs will specify the reward, mine didn’t, so I will have to come up with something. As appropriate to the ease of the quest, I think I will have Kevaar reward the player with 50 gold and a low level item. Though I could create a new, unique low level item to give the player, I don’t want to make more work for myself, and instead will choose something out of the existing item list. I want to be sure I pick something with a count greater than 1, so I don’t inadvertently give the player something that is a unique item for another quest.

I chose to give the player a silver staff. I do not need to place this reward in the game anywhere, as like the ring, giving it to the player will be handled by a special script.

I am now ready to go on to crafting the dialogue!
 

Dialogue Basics
Writing out the dialogue is arguably the biggest part of the quest creating process that also requires the most creativity. Tips for writing good dialogue is not the intent of this tutorial, and so I will be keeping this mainly to how to handle all the logistics of implementing dialogue using the Construction Set.

Topics-Based Dialogue vs. Tree Dialogue
The first thing to understanding Morrowind dialogue is that it is TOPICS-BASED Dialogue, rather than the Tree Dialogue you may be used to in other games like Skyrim or Neverwinter Nights. What this means is that the dialogue is organized by topics which the player can pick out of a list to ask the NPC about. The flow of conversation and how the player character is asking about the topics is largely left up to the player’s imagination.

This contrasts to Tree Dialogue, where the writer of the game has taken the liberty to write out exactly what the player character is saying to the NPCs. While Tree Dialogue is possible to code into Morrowind’s engine, the writing of it has to be done carefully so as to allow the player the flexibility of roleplaying their character however they want. 

Top-Down Processing
Besides being topics-based, the other important thing to understand about Morrowind dialogue is that the game engine processes dialogue in a top-down fashion. When you open up any Topic in the Construction Set, to the right you will see a window that lists all the possible responses for that Topic, called Responses. The engine goes through these Respones from top to bottom, checking to see if each Response matches the parameters you've given in the Speaker Conditions section. It stops once it finds one that does match, and this is what gets spit out at you in the game itself.

As far as developing quests goes, we then have to be very careful of tagging each Response with conditions so that it shows up only when we want it to. The engine will pick the first response it sees that even remotely matches the right conditions, meaning the most general Responses should be put at the very bottom of the list.

Below is a quick list of possible parameters and when you might make use of them:

ID
Here you can pick the ID of a particular NPC. Once selected, only this NPC can say this Reponse.

Race
This narrows down the speaker to a particular race. For instance, you may want to write out a response that makes use of Khajiit's special grammar, and only give it to Khajiit.

Class
Similarly, speakers can be narrowed down to a particular NPC class. For NPCs, classes also are often the NPC's profession, so be sure to check out the available list of classes to see which ones may be most applicable.

Faction
This limits the dialogue to NPCs who only belong in a certain faction. Remember that NPCs can only belong to one faction at a time.

Rank
This limits the dialogue to NPCs who have the rank selected, or a higher one. A faction must be chosen first before this option becomes available.

Cell
This limits dialogue to only appear when the NPC is placed in the given cell, or any of the cell's child cells. This is most useful for rumors that only appear in certain towns, or for NPCs making comments about the building they're in. If the NPCs move out of the cell, the dialogue will no longer show up, so you want to be careful selecting this option if the intended speaker(s) move(s) around.

PC Faction
The player has to belong to the selected faction for the dialogue to become available. 

PC Rank
The player has to be of a certain rank for the dialogue to become available. You must first choose a faction for this option to become available.

Sex
This is to limit the dialogue by the NPC's gender. (For dialogue that is based on the player's sex, see Function/Variable)

Disp
This stands for Disposition, or the number in the blue bar that denotes how positively the NPC sees the player ingame. For this dialogue to appear, the NPC's Disposition number must be greater than or equal to the number in the Disp box. 

Function/Variable 
This section has a series of boxes that allow you choose more complicated variables than the ones above. I've listed out some of the more commonly used ones below.

Item
The player must have the specified number of Items. Note that generally you do not want to use the = operator, or else the player must have exactly this amount of items, no more and no less!

Journal
The player must be at the specified stage (index) in the quest journal. A majority of your dialogue entries for quests will make use of this function, so I will go into how to make use of this later. Note that you can specify the quest as well as the index. This is particularly useful for making quests that are part of a series, or refer to events that went on in other quests!

PCRace
The player must belong to the specified race. Note that the value for race is only set once in character creation, so this function may break when working with mods that add more playable races. Each number refers to the races in alphabetical order, like so:
1 = Argonian
2 = Breton
3 = Dark Elf
4 = High Elf
5 = Imperial
6 = Khajiit
7 = Nord
8 = Orc

PCSex
The player must belong to the specified gender. Males have a value of 0, while Females have a value of 1. (Not to be taken literally, ladies; you're always #1 in my heart anyway!)

Weather
This dialogue when only shows when the weather of the appropriate sort is happening outside. Very useful for Khajiit complaining about the rain! This may not work as intended when indoors.
0 = Clear
1 = Cloudy
2 = Foggy
3 = Overcast
4 = Raining
5 = Thunder
6 = Ashstorm
7 = Blightstorm
8 = Snowing (Bloodmoon required)
9 = Blizzard (Bloodmoon required)

Now the "Fun" Part: Scripting!
Now, I know most of you who make quests care more for making stories and fleshing out characters, and go a little pale when it comes to the scripting. I'm here to reassure you that most of Morrowind quests can get by with just a few scripting snippets, so there is no need to feel overwhelmed when you delve into the CS's scripting commands! I have taken the liberty to jot down here some of the most common scripts and how you would implement them in a quest.

That said, there are a ton more commands you can work with to affect your gameworld in all kinds of ways. The purpose of this tutorial is not to list out every scripting command that can be used in Morrowind however, so I will have to point you towards some excellent websites such as (link) for that!

When writing quests, there are three main places where scripting is accessed and implemented. These are scripts implemented through dialogue, scripts attached to Objects (including NPCs), and finally scripts that aren't attached to anything, and must be told when to run.

Scripts Implemented through Dialogue

The  first and most common place you will find scripts is implemented in the dialogue window, in the Results box.
(picture of Respones bo with coding in it)

Unlike Object scripts, which only start when specified conditions affect their attached Object, dialogue scripts are triggered the instant the player clicks on a dialogue topic and is navigated to the appropriate Response. This timing is especially important to keep in mind for things like playing sounds or blacking out the screen, as these will happen a split second after the player clicks, usually not giving them time to read the dialogue itself.

It should also be noted that unless otherwise specified, dialogue scripts affect the speaker of the dialogue, either telling them to do something, or making something happen to them. Otherwise, you can specify another Object for things to happen to with this syntax:
"PutObjectIDHere"->PutRestofScriptHere
Eg.
"fargoth"->SetFight 100 
would make Fargoth very mad, even if this script was put into a dialogue Response spoken by Kevaar.

Journal "Quest_ID", Index#
The first and most important script is that of Journal Updating. As explained before, the journal organizes your quest into steps, and in order for the player to progress through these steps, you have to tell the computer when to move the player on to the next one. In order for my Kevaar Finds a Shiny quest to even begin, I must start adding this script to any pivotal Respones in my quest dialogue, like so:
Journal "TR_KevaarShiny" 30
This updates the quest to stage 30, and the player will be able to read whatever I wrote for that entry in their journal.

AddItem, "ItemID", #ofItems
RemoveItem, "ItemID", #ofItems
This is the primary way you will give quest items to the player, both when you hand them rewards, as well as quest items, such as that special letter they need to read or deliver on to the next person. The syntax goes like this:

AddItem ,"TR_fargothring", 1
OR
"ReceivingNPC"->AddItem, "TR_fargothring", 1

ProTip: Note, because the game engine is stupid, it will try to remove items even if the player or NPC in question doesn't have any, causing a crash. This is rectified by having the object be one of the Speaker Conditions, or adding this code into the Responses window before you do the RemoveItem command:

if ( player->GetItemCount, "TR_fargothring" >= 1 )
player->RemoveItem, "TR_fargothring", 1
endif

StartCombat "AttackedNPCID"
Sometimes you will want NPCs to initiate combat with the player, or with each other. This is done through the StartCombat command. The syntax goes likes this:

StartCombat "fargoth"
or
"TR_Kevaar"->StartCombat "fargoth"

When making two NPCs attack one another, you must tell BOTH NPCs to attack one another, or one will stand there stupidly as he gets beat on by the other. As you can see in the dialogue above, one of my attack commands specifies the actor and the other doesn't. Since this is written in the dialogue window as one of Kevaar's Responses, the game engine automatically assumes he is the one doing the attacking unless I tell it otherwise.

ProTip: As the game pauses while in dialogue, usually this script is also paired with a Goodbye command, so that the player can't keep chattering away while the NPC is trying to attack someone. While not adding a Goodbye won't break the game, it wouldn't seem very realistic.

ModDisposition #
Remember that Disposition thing I talked about earlier when talking about Speaker Conditions? This the command to change how much the NPC likes the player. While there are a few hard-coded instances of this (such as when stealing from an NPC or joining a new faction), most NPC relationship dynamics have to be done by hand. This is usually done in increments of 5 to 10, though a particularly heroic (or villanous) act may net the player a jump of 15. Syntax examples are below.
For positive disposition gains (the NPC likes the player more):
ModDisposition 10
For negative disposition gains (the NPC dislikes the player more):
ModDisposition -5

FadeOut, #
FadeIn, #
This command causes the screen to fade to black. ALWAYS PUT A FADEIN COMMAND AFTER A FADEOUT ONE, or else your player will be stuck looking at a blank screen....foreeeeeever.

You can customize how long the fadein and fadeout is by adjusting the number that follows the command, though I find 1 second is enough to symbolize the passing of time, such as when you train.

If, ElseIf
As the Results box is indeed a scripting window, you can use this kind of scripting in it! This is most often used in the conditioning of Choice commands (see below), as most other modifiers that you could put in here will already be handled by use of the Function/Variable Speaker Conditions or the order of Responses in the dialogue window.

Always remember to pair each "if" statement with an "endif", or this script will not compile correctly!

Goodbye
An old standby: this is how you force the player to stop talking to an NPC. Unfortunately this does not allow for the "Goodbye" text to be customized. The syntax is simple. You just write "Goodbye".

As I'm sure you've noticed while playing through Morrowind, there is no way to for the player to get around this beyond straight up reloading the game or clicking on Goodbye. When used in conjunction with another script such as Journal or (attack), this is how you keep the player from trying over and over to ask the same thing of an NPC.

Choice, "Text", #
Ah, I save the best for last. The Choice command is how you write Tree Dialogue into the game. The use of this script must be paired with a Function/Variable speaker condition. The script you put in the Results box looks like this:

Choice "Yes, I will help you." 1
Choice "No, get lost." 2

When I write in the above, the player will have the option of choosing either option 1 or option 2 as their character's response.

Let's say the player chooses 1. First the player gets the message that they told the NPC "Yes, I will help you", as I wrote. Next, the game engine goes back over Responses in the same Topic, until it comes across the first Response that is conditioned with Choice == 1. (This is why most Choice conditioned responses appear at the very top of topics). Then, it reads out whatever you wrote into the Choice == 1 Response to the player, implementing any other scripting in the Choice == 1 Results box, such as journal updates, the NPC attacking the player, yet another Choice, etc.

These can be done in any topic, including the Greetings, so long as all the Choice responses are kept within the same topic. If you put your Choice Response into "little secret" instead of "ring I found", the game engine will never find it, even though Kevaar telling you about the ring he found may indeed be considered his "little secret".

If I wanted some Choices to only show up based on certain conditions, I could do it like this:

if ("player"->GetMarksman >= 35)
Choice "Yes, I know how to use a bow." 1
elseif
Choice "I'm sorry, I don't know how to use a bow." 2
endif
if ("player"->GetLongBlade >= 70)
Choice "Actually, I'm much better with a sword." 3
endif

In this example, if the player's Marksman skill is greater than or equal to 35, they will see the option to tell the NPC that  they know how to use a bow. Otherwise, they can only say they don't know how. They also have the option to say they'd rather use a sword if they have a high enough Long Blade skill, but this option won't appear at all otherwise because I included no elseif option.

Complicated dialogue trees can be implemented by using lots of Choice and if/elseif commands like this, though I warn you, it is very easy to get lost in your own writing. It is often best if you can limit conversations to less than 10 choices, or draw yourself a labelled diagram.
(diagram tree)
Although it is tempting to write out all dialogue in this way a'la Neverwinter Nights, it's frankly better if we work within the style of the game engine, and only use this command when the player is indeed making a choice that could affect the entire questline, not just telling the NPC that they prefer the green drapes over the blue ones. Quest-heavy mods may break this convention, but in Tamriel Rebuilt, we prefer all Choice dialogue to be to the point and used only if there is no other way of getting the same scene across.

Pro Tip: In playing through the vanilla game, you may notice a lot of dialogue where you can click on "Continue" to give you another paragraph. This is actually done by using the Choice command, and writing "Continue" as the choice text. This is primarily done to break up long chunks of dialogue. Be warned however, that just like the Goodbye command, the player will not be able to do anything but click on your Continue or reload the game. It is best to split up very long monologues into multiple topics orto give the player the chance to leave the conversation every third Continue for this reason.

Scripts Attached to Objects

In general, scripts attached to Objects directly affect those Objects, including but not limited to telling signs how to swing in the wind, lights when to come on and off to follow day/night cycles, vampires how to infect their victims, and smart NPC followers like Julan how not to get lost on random rocks. Obviously, there are a ton of things you can do with these, but when working with quests, there are _ major uses: kill counters, Force Greetings, and activators.

Remember, that these can be accessed through the Object window. They can also be accessd by clicking the Script button, but don't forget to then attach them to the Object later!
(picture of Object window and script button)

OnDeath
In quests that involve killing off a unique NPC, you may find a code snippet something like this in the NPC's attached script:
if ( OnDeath == 1 )
Journal "JournalID" 15

In coding language, this means that when the game engine detects the death of your NPC, it will update the journal to stage you told it to. This is useful for quests where the NPC must kill a certain monster or person, but can also be used if you want to put in another quest branch if your player killed off the wrong guy as well.

For instance, in my simple quest, I could attach this script to Fargoth:
(code)

This will update the journal to an entry reading that I murdered poor Fargoth, and after writing out and properly conditioning dialogue responses for Kevaar, he will yell at me for being a cold-blooded killer.

ForceGreetings
Sometimes when taking a stroll through the lovely landscape of Morrowind, you will be rudely accosted by an NPC begging you to find her beloved or keep him from being eaten by rampaging kagoutis. This is accomplished through an Object script, and it goes like this:

if ( GetDistance Player <=256 )
ForceGreeting

Basically, when the game detects that the player is within a certain distance of the Object the script is attached to, that Object will start a conversation with the NPC. This conversation follows all the rules of dialogue initiated by the player, including Greetings and Topic orders. This is why many Force Greetings find their way in Greeting 1 or 2, so as not to be overriden by more general dialogue tied to the same zone or NPC characteristics.

Often these scripts will include further conditions to keep the computer from incessantly checking where the player is (which can slow down your mod). Here are two examples of these:

In this script, the computer checks where the player is every 4 seconds, instead of every thread:
(timer script)

In this script, the computer starts checking where the player is once they have entered a certain zone:
(zone script)

Depending on where and how you want your ForceGreeting to happen, you may use one or all of these scripts to keep your computer chugging itself to death.

Activators
These are scripts attached specifically to doors, levers, chests, beds, and other interactable objects in the game world. While these are more often used in level design (for instance, putting a trap on the button you push to raise and lower a platform), they can also be used to further a quest.

In this example, I want Kevaar to yell at the player if they try to break into his secret stash in the barrel beside him. Since barrels cannot be locked, and the dialogue for being caught stealing is generic, this allows me to make Kevaar be more or less forgiving when he notices the player poking around in his things.
(code)

As you can see, this is a simple Journal Update command. See the common theme? Now when I go back into Kevaar's dialogue, I can make him grow interested in the player's thieving ability instead of attacking them for touching his things:
(screenshot)

NoLore
You may notice that some NPCs do not have the full list of generic topics like "Morrowind lore" or "Balmora", but instead only talk to the player about topics related to their quests. This is done by attaching a NoLore script to them.

There are three parts to making  functioning noLore script. First, at the beginning of the script, you must declare it as a variable. (For those of you without scripting knowledge, variable declarations go at the top of any script, after the Begin ScriptName line. They are necessary for the computer to be able to understand and use your variable names in the rest of the script text, instead of telling you you are using a command it doesn't know.)

short NoLore

Next, in the body of the script, you must set this variable to 1.

set NoLore to 1

The third part is only applicable if you are making your own landmass or quest mod that includes more generic topics than the ones the vanilla game gives us. Whenever you add a generic topic, you must put this in the Functions/Variables part of the Speaker Conditions:

Function, NoLore, == 0

Now any topic tagged with this Function won't appear whenever the speaker of the dialogue has your NoLore script.

Companion Share
This mainly applicable for NPCs that will be longterm followers of the player. Companion Share is a hard-coded function that allows the player to manage the NPC's inventory by clicking on "Companion Share" near the top of the dialogue window. By default, this is turned off, but we can turn it on by putting this line in with the variable declarations in the NPC's script:

short Companion

Followed by:

set Companion to 1

The game engine will take care of the rest!

On-Run Scripts

And finally, there are scripts that you must tell the game engine to start running, either through putting  StartScript "ScriptName" into a the dialogue Results window, or into a script attached to an Object. Otherwise, these scripts are just floating around in the game engine like so many letters in a smokecloud and do nothing at all.

These are often best used when you want the game to do lots of commands or check lots of conditions all at once in the background, as it will not slow down the game while it is being compiled and run. They can also be used when you are trying to affect multiple Objects at a single time, or when it would just plain not make sense to attach it to any one object in the game world. This kind of script also gives you more flexibility in just when you trigger them, though I'm afraid I will have to leave it up to your imagination how this can be useful.

As I am keeping this tutorial to scripts that are useful in quests and dialogue specifically, I will be giving you an example from a Tamriel Rebuilt script:

(add topic script)

Long script short, this is used to add topics to the dialogue window. As you (should) know by now, most new topics are called into existence by using them in a snippet of dialogue. Some things, like ingredients lists or place names, are just too long, unwieldy, or impractical to add to the dialogue this way. The solution? You run a script like this.

This particular script can also be used if you are simply paranoid that the traditional way of adding your topic to the dialogue list won't work, though beware, most players are used to scanning for clickable blue text when doing quests, so you may not want to tie any pivotal information to topics added in this manner.
 

And from azeis. Also keeping giant smiley because it amuses me.

Welcome to my second tutorial in the series of learning how to make quests and dialogue! I write this assuming you have already completed my first tutorial, "Kevaar Finds a Shiny". If you haven't, I can't ensure you will understand everything I am talking about here, and can only offer you blank looks or impatient glares for not doing your homework! I will also be writing this tutorial as a series of plugins, or expansions, to the "Kevaar Finds a Shiny" quest made in the first tutorial. This means you will be working off of the completed quest from the first tutorial, so you really ought to go do your homework, don't cha know.

The first thing I wanted to touch on was combat. Though there are plenty of interesting lore tidbits or whacky NPC personalities to discover just running about town and talking to people, my quests would quickly get rather boring if all of them were done this way. The point of an RPG is to adventure, after all!

So the first thing I want to do is go back to my basic quest design and write in a combat scene. After some thought, here is my updated design:

1) The player talks to Kevaar, who tells them about a ring he's found. He asks the player to find its owner.
2) The player asks around town, and discovers the ring belongs to Fargoth. Fargoth asks the player to get the ring back for him.
3) When the player returns to Kevaar, they find Kevaar has been cornered by a scamp. They must kill the scamp in order to speak with Kevaar.
4) Kevaar thanks the player for their help, and assures the player he will return the ring to Fargoth by himself.

Next, I look at my quest journal entries. I see I will need at least one more entry to handle this extra quest step. Luckily I remember to put a gap between Indexes 50 and 60 so that I could add more quest steps here. Here is my new shiny (don't tell Kevaar) quest step:

Journal Index 52
I returned to tell Kevaar about the ring's owner, but found him being attacked by a scamp! He can't speak to me until I kill it.

(picture?)

Creating the Scamp

Next, I want to be sure I have all the Objects I will need to create this quest. My design only has the inclusion of one new Object from my original design, and that is the scamp itself!

To create it, I will first navigate to the Creature window. Since the creature I want to make is of a kind already present ingame, I will scroll down to "scamp", right-click on it, and choose Edit. I get a window that looks like this:

(scamp window)

This should look familiar. Creatures are handled in a similar way to NPCs in the game engine, though they will have different stats and a few different functions such as Movement and Blood Texture. For the purpose of my quest, there is very little I need to edit here, as my new creature will just be your ordinary scamp. 

ProTip: Consider when you expect the player to encounter your quest so that you can appropriately level your creatures. Since this is a starter town, dumping even a scamp on the player may be a good recipe for player death, so I might want to consider nerfing the scamp, such as making all of its attacks only 1 - 5 damage, or setting its health to 15. With an eye towards detail, I could then change the scamp's Scale to 0.75 and rename it Stunted Scamp--if only so the player doesn't then go around proudly bragging that they now can defeat scamps without realizing this one was a gimme!

There is one change I need to make regardless though, and that's creating a new ID, so that my editting of this Creature won't inadvertently cause changes to all scamps game-wide. You should already know how to do this from the previous tutorial, but in case you've forgotten, here: type a new ID into the ID subfield, then click save. The CS will ask you if you want to create a new Object. Click Yes.

(are you sure box)

The window will close, and I will have to find my scamp and reopen its window. Now I am ready to begin customizing my scamp without fear I might change all scamps present in the game!

While I'm here, I also want to check my scamp's AI package. Since scamps are a hostile creature normally, I will probably not need to change anything here, but adding a Creature for the player to fight only for the Creature to...not fight would be rather anticlimatic so I always want to check!

(picture of AI window)

I see that the scamp's Fight value is set to 90. Good. This means it will attack the player as soon as the player gets close enough.

Scripting the Scamp to Appear

Now there are several ways I could do this, and the choice is yours. I have taken the time to explain the methods and what situations they are best used for. I highly recommend you create a Save of your mod now, so you can go back and try each of the Methods on a clean .esp.

Disable Script Method

The first way is through use of a Disable script. In this method, I place the scamp ingame where I want the player to encounter it. I then attach a script to the scamp so that it is disabled (essentially invisible) except during the appropriate quest step. This method is best used for statics (aka scenery) or other Objects that I want placed in an exact location and position.

The first thing to do is place my scamp where I want it. I want it to attack the player in the Seyda Neen Lighthouse, so I open up the correct interior and place it inside.

(pictue of placed scamp)

Next, I want to give the scamp its disable script. I open up its stats window, then locate the Script subfield. I click the "..." button next to the drop down to write my script:
(picture of button)
(picture of script)
 

This may look rather scary to a non-coder, but have no fear. In this script, I have simply told the game engine to check if the scamp is Disabled ( GetDisabled == 1 ). If it is, check what stage the quest is on, and if on Index 50, Enable it and update the journal so it doesn't keep trying to enable it. Otherwise, if it is not Disabled, and if the quest is still at a stage where it should be, Disable it.

Pro Tip: The script will keep running in a loop for as long as the player is in the same cell as the scamp, checking every thread if the scamp is disabled or not. For the small Seyda Neen Lighthouse cell, this shouldn't cause much of an issue, but if this were in the middle of the city, I might want to consider alternative ways of writing this script so that the computer has one less thing to worry about among so many Objects.

And there we are! The scamp has now been placed and is waiting in Oblivion to appear! I can move on to writing in Kevaar's reaction to it, or, I can reload my saved .esp and try out some of the other methods for making it appear.

PlaceAtMe Method

Another method involves talking to Kevaar first, and does not involve the use of a script attached to the scamp. Instead, I will open up my old friend, the dialogue window. In this method, I want to write this scene as if the player is ambushed by a scamp shortly after speaking to Kevaar.

First, I give Kevaar a new Greeting, to appear only when the player has returned from talking to Fargoth: in other words, during the Journal stage 50.

Journal "TR_KevaarShiny" = 50
Hello! You've come back! Did you find the owner of the ring I found?

Now while I could summon the scamp with this Greeting, putting scripts in the Results window of Greetings is risky. As you've seen when creating Greetings, there are many many other Greetings that may override mine depending on the circumstances the player finds themselves in when speaking to Kevaar, and so my quest may not always trigger. To circumvent this, I would either need to put this Greeting among the Greeting 0's or 1's, or I could instead move the triggering script into its own Topic.

To be on the safe side, I will do the latter. The player will be expecting to click on the Topic "ring I found" to advance the quest with Kevaar, and so I can write in a little surprise for the player instead. I start off with writing in a new Response to the "ring I found" Topic:

"That was quick. Are you sure you didn't have any trouble on the way? Wait. What is that? B'Vehk, look behind you!"

Like all Responses, I will want to make sure this is Conditioned properly so it shows up when I want it to. For instance, though I would want to condition this Response with Journal "TR_KevaarShiny" = 50, I already have another Response that is conditioned the exact same way! I would want to make sure this new Response goes on top of the old one, or it would never appear.

Then, to summon the scamp, I will then want to add these three lines into the Results window:

Journal "TR_KevaarShiny" 52
Goodbye
PlaceAtMe, "TR_scamp", 1, 120, 3

The Journal script you have seen before. This updates the quest journal so that it is on the next step of the quest. This serves the additional of role of making sure Kevaar can't keep warning the player about the scamp when the "ring I found" Topic is clicked, and so inadvertently summoning an endless pile of scamps for the player to deal with.

The Goodbye script is also one you have probably seen played out ingame before. This forces the player to end the conversation by clicking "Goodbye", and is often used in conjunction with dialogue that ends in a fight scene, as otherwise the player would be free to chat Kevaar up for hours while the poor scamp is drooling behind them, waiting their turn.

The PlaceAtMe script is then the command that summons the scamp beside Kevaar. The first number is the amount of scamps you want to summon. (While you COULD summon more than one, they would be stacked on top of each other at first, and hence look rather funny). The second number is how far away from the calling NPC (in this case Kevaar, as it's Kevaar's dialogue) you want the scamp to be. The last number is where in relation to Kevaar you want the scamp to be. 0 is in front, 1 is behind, and 2 and 3 are to the left and right side, respectively.

For the sake of immersion, it's worth noting that PlaceAtMe places an Object immediately, with no flash, bang, or puff of smoke to accompany its sudden appearance. This function is then best used when the object will be placed out of sight of the player, such as when they have their back turned or their nose stuck in a book. You may notice that in my above scheme it's possible the scamp will poof into existence where the player can see it. This is when you might want to also consider using PlaceAtPC instead.

You can do much the same effect using the PlaceAtPC script (the syntax is the same, just "PC" instead of "Me"). The only difference in function is that the object will always appear in relation to the player instead of in relation to the calling Object. However, in a cramped interior like the Lighthouse, this is risky, as the player could be standing with their back to a wall. Though the game engine will make best effort to make sure the scamp is placed in such a way it is still "inside" the interior, placing it right on top of the player if it has to, I have better control of exactly where the scamp appears by using Kevaar as a reference instead. For our quest, it becomes a tossup of which function you prefer.

Pro Tip: To better offset the sudden appearance of the scamp (or any other object) in the player's field of vision, you could make use of PlaySound "sound id" and/or write the line FadeIn, 1 into your Results followed by FadeOut, 1 on the next line. PlaySound plays the given sound once. I could make it seem like the scamp appeared out of Oblivion by using the sound ID "mysticism hit", or that it jumped from a hiding place by using the sound IDs "Body Fall Medium" or "scamp roar" (choose one, for unfortunately without creating a special timer script, both sounds will be played at once). FadeIn/FadeOut makes the whole screen turn black and is a good indicator of the passage of time. However, since it may seem a little strange to insinuate that the player was standing staring slack-jawed at Kevaar for an indeterminate amount of time while the scamp sauntered into position, the PlaySound trick alone is probably the best pick.

As you can see, the PlaceAtMe method of placing the scamp is dependent on the position of Kevaar (or in the case of PlaceAtPC, of the player), and so can move around if Kevaar (or the player) has moved around. This contrasts to the Disable method described above, where you have already told the engine exactly where you want the scamp to appear. I'll leave it up to you to decide which one makes the most thematic sense, and how you may make best use of these methods for future encounters you may script for.

ProTip: There is actually a third method, PositionCell, X Coord, Y Coord, Z Coord, Rotation, "CellID", that can be used to summon the scamp. Like the Disable method,  PositionCell allows you to place the creature exactly where you want it, and unlike the Disable script, is only called once (usually in a Dialogue Result) and so may be easier on the computer.  This method is technically better suited for moving Objects than summoning them though, as it won't work unless the Object has already been placed in the game world. (In the case of the scamp, this placement could be in a test cell or sectioned off room in the lighthouse that the player otherwise doesn't have access to.) The Object being moved must also have a unique ID, so that the game isn't trying to figure out which guard out of _ guards you're trying to move.
 

Finishing Up the Encounter

Now that I have made sure my scamp will be summoned at the appropriate stage of the quest, I want to deal with the aftermath. While most players will kill the scamp and that will be that, there will always be that smart player who tries to magically calm it instead, or the cowardly one who tries to talk to Kevaar anyway with it chewing away on their back. While in some cases this may be appropriate, Kevaar has a particular fear of scamps after walking into a house with over 1,000 of them crammed inside, and wants the thing dead before he can even think of talking to the player again.

Just like summoning the scamp, there are a couple ways I can do this. Once again, you may want to consider saving your mod now so that you can go back and try each method with a clean .esp. These same methods can also be used as general kill counters, such as when giving the player a quest to kill a certain guy for a Morag Tong writ, or become the next Saint Jiub by slaying 5,000 cliffracers.

First, both methods entail making another special Greeting for Kevaar, intended to block progress while the scamp is still alive This Greeting will have to go in Greeting 1, right after the Oath of Silence Greeting, so that it can't be overriden by anything else. As usual, I will want to condition it for Kevaar. I will also want to be sure to condition it so it only appears during Journal Index 52. Finally, I want to add a Goodbye script into the Results window, so the player can't convince Kevaar to talk to them anyway. The final Greeting will look thus:

(picture of Greeting 1, Oath of Silence "Help! Help! Oh, by the Daedra and the Tribunal above them, someone get that thing away from me!")

The next step is making the game engine aware that the scamp is dead and so the blocked Greeting is no longer necessary. There's a few different methods for determining whether the scamp is dead.

The "Dead" Dialogue-Condition Method

One method of checking for the scamp's death is using the death counter built right into the dialogue window. Opening up the same Greeting I just created above, I will add one more Function/Variable to its conditions. I choose the "Dead" Function, then "TR_scamp" in the next drop-down, then finally < 1.
(picture of conditions)

This means the blocking Greeting only shows when the player hasn't yet killed the scamp. If the player has, the engine skips right past this dialogue, and Kevaar will talk to the player as normal. This is certainly the easiest method, and can also be used when the player must kill more than one type of creature to advance a quest. For instance, maybe not only a scamp attacked, but a clannfear too, and Kevaar also can't stand clannfears because they smell. Or maybe a scamp and a clannfear AND a golden saint attacked, and Kevaar....er. Hold that thought while I retrieve him from the closet...

The OnDeath Script Method

Ahem. The second way to make Kevaar refuse to speak to the player until the scamp dies is to add a script to the scamp. This can be more daunting for new modders, as it involves editing any script I might have placed on the scamp before (such as the Disable script), as well as creating a new journal entry, BUT, because of the journal entry, this method is more useful when killing Creatures or NPCs while out in the field, as the player does not have to return to the questgiver to see if they've succeeded in slaying the right thing yet.

First, I will add a new Journal entry:

Journal Index 54
"I killed the scamp. Kevaar has calmed down enough to talk to me now."

Now, just like when I added my Disable script to the scamp, I will want to open up the scamp's attached script by clicking on the "..." button in its statistics window. Then I will want to add the following lines into the script (Don't forget to add a Begin Scriptname and End if you are creating a whole new script.):
 

This will update the journal to stage 54 once the game registers the scamp has been killed, once again allowing the player to bypass that blocking Greeting.

ProTip: The command, GetDeadCount "creature ID", can be used in a similar manner to OnDeath, with the added bonus that it can be put inside any script, not just the local script attached to the creature you're tracking for, as well as track for multiple creatures of the same type being killed. However, caution must be taken with this one, as GetDeadCount will try and count up all the instances the given monster has died in the entire playthrough each thread, much to the detriment of your framerate! For this reason, GetDeadCount should be conditioned with timers or other methods to keep it from trying to run all the time.

Finishing the Quest, Take Two

Finally, I will want to check if Kevaar will now agree to speak to the player after the scamp is slain, by checking the conditions on the rest of his dialogue. And oops, it's a good thing I did! My old "ring I found" topic was set to complete the quest only if the quest journal index equalled 50 exactly! I will need to change this to a new set of conditions:

Journal "TR_KevaarShiny" > 50
Journal "TR_KevaarShiny" < 60

Adding both of these conditions means the quest finishing dialogue will appear if the current quest journal index is anywhere between 50 and 60, but not 50 and 60 themselves (for remember, 50 is now what triggers the scamp to appear in one of my scamp summoning methods, and 60 is for when the quest has been completed). Whew, problem averted.

If I didn't do so already when testing out the different scamp methods, I now want to playtest my mod, and see if I forgot any other conditions or introduced any other bugs by accident. If everything plays cleanly, then I have successfully added combat to my simple quest!