A beginner's guide, lesson 6 - Quest Dialogue
|A Beginner's Guide - Contents
|A. Buildings and Structures||B. Scripts, Quests and NPCs||C. Appendices|
Preamble[edit | edit source]
This is the Sixth in a proposed series of Tutorial Lessons aimed at teaching how to mod TES IV: Oblivion aimed at beginners. It will build up into a complete modding course. Don't worry, there are no exams (though, there is some homework). This version was written for use on the forum. The RTF version contains additional material that was left out due to formatting limitations.
Files[edit | edit source]
I have uploaded some files in a .zip which will be used to accompany the next few tutorials.
A. BGModTutBase.esp: This contains a building, a farmhouse, and a dungeon that we will use as sets in lessons 6, 7 and 8. This file is referred to in the text as the BASE file.
B. BGModTutPlayTest.esp: This is the interim quest mod illustrating the stage you should have reached prior to polishing the mod. This is referred to in the text as the PLAYTEST file.
C. BGModAnvilCheat.esp: This is a small optional cheat mod to give users 5000 Septims to allow them to follow this tutorial if they have not yet completed the quest. (See Introduction to Lesson 4)
D. An RTF document containing the text for the first 7 lessons (as requested).
Using this Tutorial[edit | edit source]
I suggest that you modify the CS configuration file to allow you to open multiple copies at the same time. (See Introduction to Lesson 3) Open one CS window for the PLAYTEST version. You can use this to look at the expected results of the mod. We will not edit this mod. Open a second window for the BASE version (unless you want to make your own buildings - then just make a new file). This window is for your working file.
Introduction[edit | edit source]
Well, we come to it at last. It is time for us to begin to create our own quest, to design our own NPCs, and to write our own scripts. Of course it's ridiculous to suggest that these tutorials alone will teach you everything you need to know. However, I hope by the time you finish the next few lessons you will be more comfortable with the key skills needed to create your own great works. The example quest that I am using is not intended as an example of ‘Good Practice'. I have designed it to illustrate techniques, not good quest writing. The actual details of this quest are fairly unimportant. What matters are the techniques we are using.
The next three lessons will work to develop a quality version of a quest. While we will do this exercise, I have designed the quest to allow us to focus on key skills as we go on. This lesson deals with the creation of dialogue. In lesson seven we will really turn our focus to scripting, although you will begin scripting in this lesson. The eighth lesson will complete the quest by focusing on AI and Audio.
I assume that you have completed lessons one to three, and that that you have at least read through the appendix section on the Quest Interface.
Our Plot[edit | edit source]
Quests are the bedrock of Oblivion's game mechanics. We established a basic technique to progress quests in the quest walkthrough
- Set Stage
- Set Conditions for next action.
We will try to use this wherever possible.
We need to tell a story. I have read lots forum posts that begin with the phrase ‘I have this great idea for a quest'. They then go on to explain an elaborate plot which is impossible to implement, especially for a beginner. Keep it simple to start with. The designers of the game have used simple plot devices again and again in their quests. These are
- Go find an item and bring it back.
- Go find a person and bring them back
- Go find a person and kill them
and the really complex
- Go find a person take him with you, then you kill another person, who has an item which you should then bring back.
All of these ideas are clichéd and obvious. But one of the reasons a plot become clichéd is because they work.
So here is my clichéd 'recover the item' plot line.
- The player discovers that their uncle has sadly passed away. The terrible news is softened by the fact that the Uncle has left the player some property in his will. Unfortunately the courier bringing the details of where the property, is along with the key and deed has disappeared. The player has to investigate the disappearance. This will lead him to an encounter with a gang of thieves who the player will have to defeat to recover his house key and deed.
This is not the greatest plot ever, but it should allow us to cover all the main points. I have chosen to make this quest as close to the Bethesda's 'Oblivion' model as I can.
This means setting up lots of 'hand holding' journal entries and message boxes. I personally would leave a lot of these out in a 'real' mod, but that is a personal choice. For every player who wants more freedom of choice and a more obscure progress there are others who want as much help as possible.
This is at the extreme end of the hand holding scale. Please feel free to add or change any bit of the quest you feel is too helpful to the PC. Remember, this is a way to write a quest, but it is NOT the ONLY way. This tutorial illustrates techniques. I do not intend it to be a click by click guide. In fact I will as the tutorial progresses, be feeding you less and less information, and asking you to ‘fill in the blanks'
Pre-Production[edit | edit source]
Let's get started then. You can use the base files I have provided or you can create your own. Don't forget to make the file active in the CS
You will need the following props or sets
- A house, which will be our quest reward. Of course you can change the plot detail to make this reward anything you please.
- A cave system, to act as the HQ for our baddies. Again I choose a cave system. You could just as easily make it a house, a castle or even an open air camp.
- A cottage, to house the dead courier in. This could just as easily be a camp, a house or a room in an inn.
If you are using the base files these have already been added. If you are designing your own you can add these props now, or as and when you need them.
The quest is set in 6 locations
- In and around the Imperial City
- In and around Chorrol
- The Courier Cottage close to Chorrol
- The Village of Aleswell
- The Hideout of the Baddies
- Our Reward Home.
We will also need 5 named NPCs plus a few generic goons for our hero to fight.
Imperial City, Phase One[edit | edit source]
For convenience we will split the quest into a series of phases. These are artificial divisions, and are not a technical requirement
- Phase Objectives
- - In this phase we want to set up a dialogue which introduces the quest to the player character. We want the PC to visit an NPC called Vilanus Villa who will in turn give some exposition, before directing the PC to visit Chorrol.
If we breakdown the first section of the story to see what we need to do.
- Create an NPC ‘Lawyer' who I have chosen to call Vilanus Villa.
- Add a Topic/Responses that will direct the player to Villa
- Add Topic/ Responses for Villa that will direct the player to Chorrol.
- Add a ‘letter' prop to help sell the introduction.
We can add these in any order, as long as we link them correctly. There is no one way to do things.
However, one thing to consider is that any reference objects we wish to use in condition statements or scripts must exist before we can use them. For this reason it is probably best to start by adding our NPC to the game, because we will be using him as reference in some conditions.
Adding an NPC[edit | edit source]
You can, of course, create an NPC from scratch. If you right click in the Actor section of the object menu and select NEW a new NPC interface pops up. However, you will have to edit every aspect of your new NPC, including animations, so there are many good reasons not to do this.
It is far easier to edit an existing NPC. We want Vilanus to be an Imperial, so let's select an existing NPC who is an Imperial. We don't actually have to choose an Imperial, but it saves us a job. Avoid NPCs with scripts attached. Again, you can do so but you will need to remove the script, which is an extra job. I usually look for NPCs who have either a 1 or a 0, preferably a 0, in the user column. This means they are hardly ever used in the game. Let's choose the actor called TestORMale as our base.
We will place our NPC in the Foyer of the Imperial Hotel in the Talos District (ICTalosPlazaTheTiberSeptimHotel in the Interiors world space). Again this is an arbitrary choice, based on the fact that Taverns, Inns, and hotels contain public spaces which are ideal for casual contacts. If we wished to use this NPC again, we could build him a house or office to work from.
Drag and Drop the base NPC into Render Window. F key him to get him in position.
Now double click on him to open up the details for this NPC reference. Then click "Edit Base" to edit the NPC itself.
Let's briefly look at the properties on the far left of this interface.
|ID||Editor ID for this NPC. Must be unique.|
|Name||NPC name as it will appear in-game.|
|Script||Scripts can be attached to NPCs here.|
|Class||Can be defined using the class interface from the menu bar.|
|Summonable||Mainly used for creatures and defines them as able to be summoned.|
|Offset/PC Level Offset||Used to set NPC level. Either a fixed value within a defined range, or offset against PC level.|
|Calc Min/Max||These check boxes determine minimum and maximum levels for the NPC.|
|Race||Choose the NPC's race from the drop-down menu|
|Female||Used to toggle gender.|
|Combat Style||Combat Styles influence NPC choices during a fight. (see lesson eight)|
|Death Item||Used for special loot items that we don't want to show up until after an NPC is dead.|
|Essential||Essential NPCs cannot be killed and are only knocked unconscious.|
|Respawn||This NPC will respawn when the cell reloads if you check this.|
Selecting "PC Level Offset" will lock or unlock the details in the stats tab.
First alter the NPC's ID to BGVilanusVilla and the name to Vilanus Villa.
We tend to prefix all items added by a mod with a suitable prefix, like BG or BGM. This help avoid any conflicts, in the unlikely event that another mod adds a character called Vilanus Villa.
This NPC's class is Barbarian. The actual class of a NPC will only affect auto-generated statistics, and has little bearing on the interaction between PC and NPC. However, it is easy to change this setting using the drop down list under class.
We will look at levels later on in this tutorial; for now leave it at level 8. The level of a character is only relevant in combat.
For now we want to get rid of all existing AI packages. We are deleting the AI because it makes initial play testing much easier. Without any AI the guy will stay put. We don't want to have to walk halfway across Tamriel to find him when we test the mod!
Open up the AI section by clicking on the AI button.
Delete all the AI packages using right-click + delete. (This only removes them from the NPC's list, it doesn't delete the actual package)
Now select and check the ESSENTIAL flag. We want to keep Vilanus alive for now.
We can also alter the inventory if we wish. Again, by careful pre-selection we can save ourselves a job. Remember to scroll across the information in the object window to select suitable characters that match your requirements as closely as possible, to reduce the amount of work you need to do.
We want Vilanus to be a rich merchant, so he should have some decent clothes. TestORmale fits the bill. We should also remove any weapons and armor from him, as he is supposed to be a lawyer. (Note that the Hammer may show up in the render window until you reload the window, but will not show up in the game.)
We can leave his faction details alone for now.
Finally you can play around with the face to get the look you want. For now, don't spend too much time on it. You can use the auto-generator to get a rough look. You can tidy this up later in the polishing phase.
Exit and create a new form by clicking yes. We now have a brand new NPC. We will have to do some work on him later, but he is in the game.
Creating the Quest[edit | edit source]
In the top menu select CHARACTER. Then from the drop down menu select QUEST.
The quest window will open. We should be familiar with this from lessons four and five.
On the left hand side is the list of all the quests in the game. Place your pointer over this section and right click. A small selection window appears. Select NEW.
Another window pops up called New Form Editor ID This is the prompt for us to enter our Quest ID.
The ID is NOT the same as the quest name which will appear in the player's journal. This should be a short alpha-numeric name, with no spaces, that we can readily identify as a part of our mod. It must also be unique. I chose to name mine BGM001 (Beginners Guide Mod 1). When you're done, select OK.
We now have a quest. Let's look at out quest data tab.
We want to give our quest a name. This is the name that appears in the in-game journal entries. You can call it pretty much what you like. You can even use duplicate names, but that would be a bit confusing. I've chosen to call mine The Inheritance Denied.
If you remember from lesson 4, we need to choose an appropriate priority value.
We will select 50, as this is a miscellaneous quest.
The next set of decisions involves the three flags which were discussed in the appendix:
- Start Game Enabled
- Allow Repeated Conversation Topics
- Allow Repeated Stages
These three tags control when and how often scripts are run.
For now let's go ahead and select the standard Start Game Enabled and leave blank the Repeated Conversations & Stages. Now have a look at the table at the below, which contains quest conditions.
Quest Conditions[edit | edit source]
At the moment this is blank. We are going to input a condition which has the effect of limiting any conversations and dialogue topics we create in this quest to characters we would expect to speak, thereby excluding those we wouldn't (e.g. goblins and horses).
The conditions are applied to the person speaking the line, called the object. Click the NEW button at the bottom of the page.
The interface to enter conditions is split into four areas: Condition Function, Function Parameters, Comparison, and Value. There are also some flag selectors, which we will look at later.
Condition Function[edit | edit source]
This is the basis of your condition. It initially defaults to the condition GetDisposition, but clicking on this opens up a long list in a drop down window. This contains the valid functions that can be used in a conditional statement. (See later for IF-ENDIF BLOCKS)
These can be divided into sets of similar functions which I have chosen to call families.
- CAN Family: Tests if something can happen
- HAS Family: Tests if something has occurred
- IS Family: Tests if something is true
- SAME family: Test if two things are the same
- GET family: Retrieves information from game for comparison
Clearly I cannot go through each of these in turn. In truth most of their general functions are self explanatory, even if their specific use is not.
Function parameters[edit | edit source]
Some functions require a parameter to work, and some don't. It depends on the function.
Comparison[edit | edit source]
All conditional statements result in boolean values: true or false. They are all about comparing values. Each "conditional function" returns some value which we can then compare to our own set value in a few different ways: less than, more than, equivalent to, not equivalent to, etc. The comparison of those two values will turn out to be either true or false. (e.g.: Either A is more than B, or it isn't. The player has less than or equal to 5000 gold, or he/she doesn't.)
Value[edit | edit source]
This is the value we compare the conditional function value with. This can be a number or a variable.
Our condition[edit | edit source]
We want to set up a conditional function that checks whether the speaker is of the right type. I.e., that it is one of the playable races (Imperial, High Elf, etc.).
From the Condition Function list, we choose GetIsPlayableRace.
This function does not require a parameter, as it already knows exactly which races are or aren't valid player races. It will return a value of 1 if the object is a playable race, and a value of 0 if not.
From the list of comparisons we choose equals. This is represented by ==.
In the value box we select 1.000.
We now have the condition
GetIsPlayableRace == 1.
This is in effect the equivalent to the instruction
Find out if the actor is from a playable race. IF this is true, carry on. IF NOT, stop the actor from speaking any of the lines from this quest.
We have completed the basic set up for our quest.
Quest Stages[edit | edit source]
Now let's select the Quest Stages Tab.
Again, this is blank. We can add stages in the same way as we added the quest. In the column marked Quest Stages, right click and select new. The pop-up expects a number between 0-255. We tend to use 10, 20, 30, etc. to allow room for extra stages. Go ahead and enter 10. Now select new again, and enter 100. We now have two stages: 10 and 100. Now make one more stage and enter 20. Initially the list reads 10, 100, 20. But if you go back to the quest data tab and then return to the stage tab again, the list will have updated to read 10, 20, 100. The CS sorted them for us.
(Note that although the CS lists the stages in numerical order, you do not have to work through the stages in that order. Each stage is discrete and exists in its own right without reference to the other stages.)
These three stages are blank. Don't worry about this. Until we set the game up to call these stages, they do nothing. If we do call a blank stage nothing will happen.
Quest Targets[edit | edit source]
The next tab is called TARGETS. We will add all the targets at the end of lesson 7. We can add them at any stage. I found it easier to do this at the end.
We are now ready to get down to the fun bit of mod building.
Topics[edit | edit source]
Let's add some content.
Select the Topics Tab from the Quest pop up. DO NOT use filtered dialogue to add topics: this can lead to mod confliction issues.
Again, this is blank to begin with. We will add a topic which will be used at the start of the quest.
In the topic column to left hand side of the tab, right-click and select Add Topic. A pop-up appears listing all available topics for all of the quests in the game. Again we use right-click and New to get another pop-up. We need to add a one word unique topic descriptor.
You should add a topic called BGMMessage4u. (In the TutPlayTest file, the topic was accidentally named message4u - you should continue using the quest prefix.)
If you look at the top this also appears at the top of the screen, in the 'Topic Text' box. This is the topic as it will appear in the dialogue menu when you activate a suitable NPC. Try to keep these fairly short, as they will otherwise take up too much space in the topic selection menu. Let's change this to something like "Message for you."
Great! We have a topic, now we need a response. The idea here is to create an exchange where when we click on the topic "Message for you" we get a response that lets us know that an NPC - who I named Vilanus Villa - is looking for us. Of course the name is entirely up to you. Just change any reference I make to "Vilanus Villa" to suit your characters.
Right-click in the response section (underneath the Topic Text filed), and select new. A new pop-up interface appears. Ignore the bottom part for now. In the upper section type:
I hear a Lawyer named Vilanus Villa is looking for you.
Hit Ok to save.
So we now have a topic and a response. However, if you tested this mod you would not see this topic on any NPC at all. Why?
There are an awful lot of topics in the game list. If the game added every topic to every character the scrolling list of topics would be ridiculously long. So the game works like this. It only adds topics which:
A) Have a valid response (one whose conditions are met)
B) Your character knows about
Players can learn new topics in all sorts of ways. They may, as in the walkthrough quest in lessons 4-5, pick one up from an overheard conversation. They may talk to NPCs and pick up topics that way. They may witness events that add topics. Or, as in the case of this mod, we teach them the topic by doing a bit of scripting.
So are you ready to write a script?
Our First Script[edit | edit source]
We are going to write a bit of script which will add a topic to the players learned list and thus allow NPCs to use that topic when we activate them.
Before we go further it might be useful to give you a bit of a glossary. I have assumed that you have never programmed before in writing this tutorial. If you have you will be at an advantage when it comes to writing scripts.
These are the formal instructions that you place in the script to tell the game what you want it to do. The Wiki makes a distinction between what these do. It should be noticed, the differences for beginners may appear very slight.
The commands are:
-Used to identify the script obviously
-These are a set of descriptors which identify the VARIABLES used in a script
-Used in conjunction with each other to create BLOCKS of script.
-Used together with optional ElseIf and Else commands to form CONDITIONAL blocks.
-Use to break a scripts running for that run only.
-Used to assign new values to variables
- “.” or Use Reference
The full stop or period “.” is a command which identifies the REFERENCE that a FUNCTION should use.
There are a large number of functions, each of which does a unique job. There is not enough space to look at each of these in turn. However, many of the functions do group together to form ‘families', for example
One way to think of variables is as a container which stores a number. The different variables types, Short, Long etc. determined how big a container will be assigned to that variable name.
So for example
Short BOB Long BILL
This assigns a small section of the computers memory to a variable called bob (note capitalisation is purely a matter of personal clarity and style and is not important to the script compiling or running), and a larger part of the memory is assigned to a variable called Bill. The more variables the game has to remember the larger the amount of memory we use, and the slower the game runs. We want to minimise the impact by declaring as small a variable type as possible.
Many functions accept or need you to include extra bits of information called a parameter.
Player.additem gold001 100
The 100 is a parameter that lets the game know how much gold to add.
Object ID: Several functions work by doing something to a game object. Remember all the objects are listed in the object window, so objects include Actors.
Player.additem gold001 100
Here gold001 is the object id
- Reference ID
Several functions work by changing a specific example of an object. There may be many chests of a particular object type in the game and you want to add gold to only one of them. The reference ID is a unique identifier for that instance of an object. You add the reference by double clicking on the example in the render window (or by selecting edit from the cell objects window). In the object pop up dialogue box you add a unique name to the reference id box. Note that for this to happen the object must be placed in a cell. To use this reference in a script you will need to click the persistent reference check box. This tells the game to always remember that object even if the PC leaves the cell that it is in.
Player.additem gold001 100
In this example the player (a constant reference) is the reference id.
Okay let's move on
The FUNCTION we will use is called AddTopic. Its syntax (the way the computer needs it to be written so it works) is this
Firstly the use of capitals in any function is optional
addtopic ADDTOPIC AddTopic aDdToPiC
All work, and all do the same thing. It's just that AddTopic looks neater so you tend to see this used most. But don't get worried if you forget or come across script that uses capitals in another way.
The TopicID is the id name we added in the topic list. This is why it has to be unique.
Take a deep breath. Now go back to the quest Data tab. Next to the quest script box is a button with three dots … Click this and the script editing window opens up.
The Script Editing Window[edit | edit source]
The script editor is in essence a very basic text editor, used for writing and editing scripts. Many scripters use external text editors like Notepad, Notepad++, Crimson Editor, etc. to write their scripts. One reason for this is that the script editor will only save compiled scripts, which must be 100% free of errors. External editors also allow you to keep a back-up versions of your scripts.
I personally keep a large library of scripts. Some that I have written, and loads copied from forums and other mods. I can then refer to these when I need a solution to a problem.
On the menu bar at the top of the editor you will find two options, plus the standard help files.
Script[edit | edit source]
This menu has the following options available
Creates a new, empty script.
Presents a list of existing scripts. Choose from the drop down list for one to edit.
- Next Script
Switches to the next script in alphabetical order. If you changed the current script, or the current scripts needs to be recompiled for some other reason (e.g. changed variables in another script) you'll be asked if you want to save the changes.
- Previous Script
Switches to the previous script in alphabetical order. You'll be asked if you want to save/recompile.
Compiles and saves the script. If it fails to compile, the script is not saved.
Shows the list of all scripts. Choose one to delete
WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
- Recompile All
Recompiles all scripts in game. This will store all scripts from any currently loaded ESM's or ESP's into your active ESP, so it's only useful for working on total conversions. In other words DON'T USE THIS unless you know exactly what you are doing. EVER! The resulting esp. will be a) Huge and b) In conflict with the original files.
WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
Edit[edit | edit source]
Standard undo function that restores the script to its state before the last change.
- Standard redo function that restores the last change to the script if it has been undone.
- Find Text
Standard find function.
- Find Next
Standard find next function that repeats the last find from the current cursor location.
- Go To Line
Compile errors list the error by line number. Use this command to go directly to that line number.
Next is a line of icons which give you shorthand ways to do some of the menu actions. In order from left to right they are. Open, Save, Next, Previous, Compile All, Delete, Exit
Script Type[edit | edit source]
Finally there is a Script Type drop down menu. There are 4 types of script, but "Results" scripts are not edited or compiled in the script editor. We will see this shortly.
The scripts written in this editor can be Object, Quest, or Magic effect. This setting determines which objects in the editor the script can be attached to. Each script type is run in a slightly different way and it is important to let the game know which one you want your script to be. You can edit or change this at a later date if you make an error.
Okay, we want to write a quest script, so select Quest from the Script Type drop-down window.
Scripting[edit | edit source]
A script is a set of instructions for the game to run during gameplay. It has much in common with programming languages, but is not a true language per se. We do need to use a formal structure called syntax to ensure that the game can understand what we want it to do.
Let's add a bit of script then.
We need to give each script a name, and like all naming conventions that we have covered so far, it has the same basic rules. The name must unique, alpha-numeric, and free of whitespace (spaces, tabs, etc.). You should also continue to use your quest prefix (e.g. BGM) while naming your scripts.
Let's name the script BGM001QuestScript.
(Note: This should be done on the BASE version if you have loaded Both Tutorial Mods at the same time.)
We write this in the editor like this:
We could also use a shorthand version:
Many functions and command have shorthand versions. In this tutorial I will always use the full version.
Now select save.
The editor compiles the script.
Begin Statements[edit | edit source]
First we start by adding a Begin statement.
This comes in two parts. The first is the word BEGIN followed by a space. Followed by the BLOCK type statement. There are lots of BLOCK types available.
The vast majority of begin blocks run only once.
This is both an advantage and a disadvantage. Many forum posts deal with scripts that need to run continuously, but because of the block type only run once. Selecting the correct block type is a skill you will only develop by practice and observation. For the most part you will be using GameMode, OnActivate and MenuMode.
So lets type
(Remember the capitals are purely for clarity)
Now let's add the instruction
And finally the
So our script reads
Scriptname BGM001QuestScript Begin GameMode AddTopic BGMMessage4U End
We can again save our script.
(Please note, the quest script in the PLAYTEST file shows the script in its finished state and quite long. We will add small snippets of working script as we progress)
One of the most common mistakes that beginners make is to assume that because a script complies (saves), that it will work. This is not the case. The editor checks to see that your script has obeyed all the rules to make sure the game can try to carry out your instructions. It does not mean that these instructions will do the job you expect them to do. If you do make a syntax error the editor will display a pop up window detailing the error, together with a disconcerting alarm ring. It also asks you to select whether you should continue. Always say yes or you will lose your scripts.
It is always a good idea to back up scripts in notepad or WordPad. Remember you can copy a script by selecting it, and then using the shortcut CTRL-C.
Now we need to attach the script to our quest.
Open up the Quest Data Tab for our quest. Where it says script open the drop down menu and scroll down to find the BGM001QuestScript. Click on this and you're done.
Save the mod (you will need to close all pop up windows to do this)
You can now test this mod in the game, but it might be best not to SAVE the game in Oblivion as we will be changing things.
Two Problems[edit | edit source]
There are two problems with the mod as it stands:
The first problem is that the text does not stay on the screen very long, and our NPC will just look at us. This is due to the way the game handles speech. It expects to find for each dialogue response files, which we have not created. One is an MP3 which contains the sound files, and the others are lip synch files used to animate the actor's face as we carry out the dialogue. The text is supposed to appear on screen for the duration of these files. Since we don't have them yet, the text runs very quickly. In later tutorials we will look at polishing this mod to include these files. For now, these are cosmetic problems. It's irritating not to see the text for any length of time, but it can't be helped until we add those MP3's. It doesn't stop the quest running. You can repeatedly play the on-screen text by selecting the topic message for you until you get the message. (Alternatively, you could install a mod like Universal Silent Voice.)
The second problem deals with the script as it currently stands and may not be so obvious to a non-scripter. A quest script runs every 5 seconds. That means that every 5 seconds this script tries to add the topic BGMMessage4u to the players topic list. I don't honestly know what the effect of repeatedly adding a topic to the player's list is, but I suspect that extra requests to add the topic are simply ignored.
However, this is still an untidy way to script. If we only want something to happen once, we should write our script that way!
This leads us to one of the most important and common scripting ideas: a do once loop.
If-EndIf Blocks[edit | edit source]
No other command is more important to good quality functional scripts than the if command. Again those with programming experience will be at a slight advantage as you will have used these before. For the newbie let me explain little about the premise behind IF blocks.
These useful bits of code set up the ability to run selected bits of script at selected times.
We control when they run by setting conditions which must be met for the code to run. The conditions are based on mathematical relationships, and are based on numerical values.
The structure of the if block can be summarised as this
If (a set of mathematically based conditions)
- RUN THE SCRIPT INSTRUCTIONS LOCATED HERE IF THE CONDITIONS ARE TRUE
ElseIf (a second set of OPTIONAL conditions)
- SCRIPT THAT RUNS IF THE SECOND SET IS TRUE. THE CONDITION WILL ONLY BE TESTED IF THE ORIGINAL IF STATEMENT SET OF CONDITIONS ARE FALSE.
Else (No Conditions)
- OPTIONAL SCRIPT THAT RUNS IF ALL OTHER CONDITIONS ARE FALSE.
- IF THE ELSEIF AND ELSE COMMANDS ARE OMITTED THE BLOCK DOES NOTHING IF THE ORIGINAL CONDITIONS ATTACHED TO THE IF STAEMENT ARE NOT MET.
So all IF blocks, must contain an IF command, a set of conditions, some instructions and an EndIf command. The ElseIf and Else commands are optional, and add versatility to the block.
We are going to write an IF block to limit the number of times our script runs to one.
It is call a DoOnce (do once) loop and is used hundreds of times by the developers, and is a standard tool for all scripters.
First we need to declare a variable. Open up the quest script using the … button next to the quest script.
We can declare a variable anywhere in a script before it is used but by convention we usually do this at the beginning of the script before any Begin Blocks.
The variable we want will only ever have two values 0 or 1. So we can use the smallest possible variable type, which is short. We will call it DoOnce1 for convenience. You can call variable what you like as long as it is a single text string. But again it helps to make them descriptive to help sort out mistakes (Debugging) Remember Capitals are only for show.
So add the line
Just after the script name line. You can leave lines to help clarity. Again these are ignored by the program when it runs the script.
Now let's add the if block
Change the Begin block to look like this.
Begin GameMode If (DoOnce1 == 0) AddTopic BGMMessage4U Set DoOnce1 to 1 EndIf End
This is perfectly fine but it can get a little hard to read, when these if statements get long and complex. So again we use an optional convention. We indent using the tab key all lines after an IF statement, to make clear what is going on.
Begin GameMode If (DoOnce1 == 0) AddTopic BGMMessage4U Set DoOnce1 to 1 EndIf End
So this script uses another new command called SET-TO.
Whenever you declare variables they are automatically assigned a value of Zero. We can alter this by using the SET-To commands. (Note basic programmers that it is SET x TO y not SET x = y)
The format is
Set VARIABLE to VALUE
The VALUE can be any number which fit's the pattern of the variable. So for a short variable it can be any integer or whole number between (-32768) and (32767).
This can take the form of
- A fixed number like our script.
- The result of a mathematical calculation.
- The value of another variable
- Or the outcome of a comparison statement.
IF statements and Set statements both use standard mathematical comparisons
Comparison Operators[edit | edit source]
An IF statement may contain one or more comparison operators. Below is a table of valid comparison operators:
Operator Description == Exactly equal to != Not equal to > Greater than >= Greater than or equal to < Less than <= Less than or equal to
Combining Comparisons[edit | edit source]
Comparisons can be linked together using the following logical operators:
Operator Description Example && Logical AND If x == 1 && y == 1; considered true only if both x and y equal 1. || Logical OR If x == 1 || y == 1; considered true unless both x and y equal 0.
(Note that "||" is evaluated before "&&")
So this script we have written works this way.
The first time the script runs the variable DoOnce is set up and given the value ZERO.
The game runs through the script to the IF statement.
It tests to see if it is TRUE that DoOnce equal zero. In this case it is true. So it runs the script, adding the topic BGMMessage4u to the players learned list. It then sets the value stored in doonce1 to the number one. It then ends the IF statement and ends the scripts begin end block. Since this is the end of the script it stops running. About 5 seconds later this Quest script runs again. Again it comes to the test. But this time DoOnce1 is not equal to 0. So the program skips the instructions and ends the IF statement. From now on this bit of script will not run. We have added the topic once and once only.
A third problem[edit | edit source]
The third major problem is that this topic has been added to every NPC in the game. It is just about conceivable that if you complete every quest in the game and then some that you might meet every NPC there is, but I don't see how it's logical to suggest that they all might know Vilanus Villa and know he has a message for you. We need to limit who speaks to you on this topic. We must set some response conditions.
Conditions[edit | edit source]
The conditions box in the Topics Tab is used to limit who gets to say a particular response. We can limit this in many ways.
For example, Restrict by group (GetInFaction), race (GetRace) or limit to only one NPC (GetIsID), Restrict by Worldspace, City, Cell or distance from a particular chair, Restrict by Game Time, Season, Weather or progress of quest.
Open up the topics tab, select the BGMMessage4u topic and highlight the response we added earlier.
At the bottom of the window is the condition box. Again we can use Right-click + New to add conditions, or we can click on the New button at the bottom of the tab page.
These conditions are just like the ones we used in Quest Data before.
By default, all NPCs will have our new topic available. We need to use conditions to choose which NPCs can or can't display our topic.
This particular topic is a general one and we want to set some general conditions just to reduce the number of NPCs that can use it.
First let's get rid of a number of races. Why? Well, in the middle part of the window is the response box. Double click on the response to the BGMMessage4u topic to re-open the pop-up response dialog box. Have a look at the lower section and you can see a long list.
This is the list of expected MP3 files which we would need to create. It is very long; it expects both a male and female response for every single race.
We can remove some of these to make our life easier later on, when it's time to record.
Select New in the condition box with the response "I hear a lawyer named..." highlighted.
In the Condition Function drop down menu, scroll down to the function GetIsRace. Click on the Function Parameter box and a list of races will be displayed. These are the valid parameters for this function. Select "Argonian" from the list. The comparison reads == by default, so you can leave that unchanged. The value current reads 1.0000. This is value the function GetIsRace would give if the character's race was in fact "Argonian". We want to change this to the negative response: 0.0000.
In English this means:
Look at the Actor who might use this response. Check what race they are. If they are not an Argonian, then carry on. Otherwise, they are an Argonian and should not be able to use this line.
(Note that the condition Argonian == 0 is logically equivalent to Argonian != 1)
Now, let's add a few more Race-based conditions. Right-click on the condition we just created and copy it using the Copy option from the menu. Now right-click again and paste. We now have an exact copy of our condition.
Click on the parameter box and now choose "Elf". We now have two races excluded.
Repeat this process to exclude the other races, until we are left with Bretons, Redguards, Imperialsm and Nords (i.e. the Human races).
Is this some sort of cultural imperialism on my part? No, it's just that I reckon I could add an MP3 file which might sound passable for those races. Orcs, Argonians, and Khajiits have unique voice types that are harder to replicate. It is a matter of style and choice. If you want to extend the range, do so.
We call these conditions "exclusive conditions" because they exclude a group or individual from using that response.
We also want to limit the in-game locations where these lines are valid.
All major locations, including the cities, have special "dummy cells" created to allow us to use a single condition on many individual locations. The game searches for cells with a given text string at the beginning of its name. So if we select a cell called "IC", it actually triggers every cell that begins with "IC". Everything from ICPalaceLibrary to ICTalosPlazeTheTiberSeptimHotelUpstairs.
If you called a cell Icnatta or something else that also begins with "IC", even though this cell might have nothing to do with the Imperial City, the catch all nature of the "IC" description means that that cell will also be triggered. This would conflict with the Imperial City's naming prefix. This means we do need to be careful when naming cells. It also means that we can use this trick ourselves. If we create huge mods that add towns or cities, we can use prefixes in the same way. By carefully naming all my external and interior cells VeronaHouseSomethingorOther, we could then create a "dummy" (i.e., completely empty and unused) cell called VeronaHouse, which would allow us to use VeronaHouse in condition statements and identify if something was anywhere in the Verona House area.
I choose the Imperial City (again, I could have chosen any number of locations) because it is the Capital, and most players will at one point or another visit the City. It is as ever about style rather than technique and you are free to choose your own path.
In the condition box select New.
Now select condition function GetInCell. The parameter for this is initially invalid until we click on it select a cell from the menu. You can only select cells that are named and unique. Notice that all those exterior cells called "Wilderness" don't show up. If you wish to use an exterior cell, you must give it a unique name.
Set the condition to test. (This is an inclusive condition, since it includes a group in that response.)
Another way to select groups is by using factions (see lesson 7 for more details on creating a Faction)
One such faction is the ICFaction. It groups all the NPCs who are considered citizens of this city. It is a useful way to distinguish between the merchants, soldiers, and workers of the capital and a tourist from Chorrol who is passing through.
Set up a new condition.
Choose the GetInFaction function, and then choose the ICFaction from the list to get a new condition. Finally, we want to exclude our NPC Vilanus Villa from using these lines. It would be awfully silly if Vilanus himself told us, "I hear a lawyer named Vilanus Villa is looking for you." To do this we use the condition function GetIsID. Then from the parameter list we select BGVilanusVilla. Remember to set the value to == 0 (or != 1) so that your condition EXCLUDES him.
Finally, we want to set a condition that removes this topic from all potential speakers once we have met Villa.
Create a new condition. Choose the GetStage Function, then select our quest (BGM001) from the list. Change the 'Comparison' to < (less than), and the value to ten. This runs a check to ensure the PC hasn't advanced at all in the quest, effectively removing it from all NPC's if it has.
Adding Topics[edit | edit source]
We also want to add a new topic as a result of this response.
First create a new topic called BGMVilanusVilla using the method we have just used (Right Click-New). You can leave the response blank for now.
On the Right hand side of the Topics Tab window are three boxes called
- Add Topic
This is used to add a topic to the players learned list. Once added it can be accessed using the topic menu when we click on an NPC. The player can then decide whether or not to click on this.
- Add Choices
This adds a list of FORCED choices to the topic menu. All other options are removed, and the player must make a choice to proceed.
- Add Links from
This adds a single FORCED topic which again forces the player to select that option to proceed. It links to a previous response. By using this we can set up long forced conversations.
It is probably best to use the Add Topic box, on this occasion, so we can use the topic several times. Again a bit of preplanning will allow you to use the same topic for several purposes.
Now go back to the BGMMessage4u topic and in the Add Topic box to the right, right click and add the BGVilanusVilla topic. Now when we talk to an NPC about the message we will have a new topic added to our learned list called BGVilanusVilla. It won't show up in the game right now as we have no valid responses.
Finally in the result script box type the following:
SetStage BGM001 10
Now click the COMPILE button.
This executes a stage bump. The quest is now set at STAGE 10
Let's summarise what we have for this first topic
|TOPIC||Message for you|
|RESPONSE||I hear a lawyer named Vilanus Villa is looking for you.|
SetStage BGM001 10
I'll use these summaries throughout these tutorials. I have used this table as a template when planning my own quests, and I find it really useful. Remember, if you get stuck refer to the PLAY TEST (BGModTutPlayTest) version to see how it should look.
Stage Update[edit | edit source]
Now return to the quest stages tab.
We have now progressed through the quest to stage 10. We can of course leave this blank. Sometimes we want to stage bump simply to activate/deactivate conditions that use the GetStage function. However, we can also use this stage bump to do a few things. We can add a quest stage result script to carry out some script instructions relating to the quest and we can add a Journal entry. Let's do this. It's the same old routine. Right Click and new in the Log Entry box. Add a suitable bit of text like:
I have been told a lawyer called Vilanus Villa is looking for me. I should find out where he is staying. He may have important news for me.
Ok, we have now added a topic called BGMMessage4u.
For now, save and go test.
You should now find that this topic only appears for human characters in the Imperial City. Try in other locales like Anvil, etc. to make sure. When you're done, come back and we can move on.
When you click on the BGMMessage4u topic in the game the topic Vilanus Villa will now automatically be added.
I don't intend to continue to give you a click-by-click method for every topic and response. Remember the basic idea of right click and select.
Let's move on.
Select the BGVilanusVilla topic we added earlier and add a response (See table below). This response should direct the player to the Talos District of the Imperial City.
We need some conditions.
Since this is a direct follow-up from'BGMMessage4u, we can use the same conditions to do the job. In the BGMMessage4u condition box, right click and select copy all conditions and then paste these into the BGVilanusVilla response.
This response is fine, unless we're talking to someone who's already in Talos Plaza.
|TOPIC TEXT||"Vilanus Villa"|
|RESPONSE||"I believe he's staying in Talos Plaza."|
|ADD TOPICS||No add topic|
|RESULT SCRIPT||No script|
We should also add responses that only work inside Talos Plaza. This next one should direct the player to the Imperial Hotel where we placed Vilanus Villa. Again, we can copy the conditions by using the copy and paste method, and then change the last condition (GetInCell 'ICTalosPlaza') to 1. (You could also duplicate the entire response by right-clicking and selecting copy, and then edit the duplicate from there.)
|TOPIC TEXT||"Vilanus Villa"|
|RESPONSE||"I believe he is staying in the Tiber Septim Hotel."|
|ADD TOPICS||No add topic|
|RESULT SCRIPT||No script|
If you wanted to get really flashy you could add another response for the occasions when we ask NPCs about Vilanus Villa inside the hotel itself. However, I have not done this to save a bit of time. Feel free to try this yourself. A response like "Yeah I've seen him around here." would do. Don't forget to copy the conditions and alter the GetInCell parameter. Also remember that GetInCell matches the beginning of the cell strings, so you should add another GetInCell condition to the second response which excludes the Hotel cell (so that the response "I believe he is staying in the Imperial Hotel." shows up everywhere in Talos Plaza EXCEPT for the hotel itself).
Using the GREETING topic[edit | edit source]
Another way to pass on information via dialogues is to use the GREETING topic. If you remember the discussion in Lesson 4 about how conversations work, all dialogues begin with a GREETING, which is selected by the game from the GREETING topic. If we add our own greeting and set the right conditions we can force a start to a dialogue. In the topics tab add GREETING. This topic already exists, so you will not need to create a new topic when the list appears.
We can now add Vilanus Villa's little speech. This is quite a long response so we should split it up to reduce the amount of text that appears on the screen at any given time. Add this response first to the GREETING topic. Note this is blank because there are no GREETING responses added by this quest yet.
Hello, my name is Vilanus Villa and I've been looking for you. I'm afraid I have some bad news.
Now click OK to add the response.
Then in the Response Details box (not the upper info box), add a new line of response text. You'll get a new interface to write in.
Your uncle passed away peacefully in his sleep.
Then add another:
I have been asked to look after his last will and testament.
We can go on adding new lines to this response info if we wish. In the top box we can see the number of responses increments to 3. The text appears in the top box as:
Hello, my name is Vilanus Villa and I've been looking for you. I'm afraid I have some bad news. || Your uncle passed away peacefully in his sleep. || I have been asked to look after his last will and testament.
With the || indicating separate lines of this single response.
We need to add some conditions, to control who says these lines. This is very important when using the GREETINGS topic as this is so wide spread within the game. While it is silly that every character could respond to BGMMessage4u, it is dangerous to have an unconditional greeting, as this might override every other greeting in the game and prevent other quests from working properly.
Limiting a response to just one character is easier than using groups.
We can use the GetIsID function for this.
We need to have an NPC reference, which is why we built BGVilanusVilla first. We will also restrict this response to the opening stage of our quest.
- GetStage 'BGM001' <= 10
- GetIsID 'BGVilanusVilla' == 1
Now we want to add a new topic called BGWill. However, there is an issue (and many thanks to Hecks for pointing this out) when adding topics to the GREETING or indeed any existing Bethesda topic. For technical reasons, the topic might not get added if more than one plug-in is attempting to use GREETING to add a topic. I'll be honest and say I don't know why this happens. It's not difficult to work around once you know the issue exists. When I found out it took me thirty seconds in the CS to fix.
First create a new topic called BGWill.
Now add this to the result script for the GREETING response.
The speech that Villa gives contains a lot of exposition, and we don't want to force the player to repeat this every time.
We can stop this by setting up a pair of conditional responses.
Conditional Pairs[edit | edit source]
These are a very common device used throughout the official quests. We set up two response infos to the same topic. We then use a quest variable or a function condition to control which of the two responses is said.
These might take the form
Response 1: Long Explanation Response 2: Short Explanation Response 1: Female PC Response ‘Morning Ma'am' Response 2: Male PC Response ‘Morning Sir' Response 1: ‘Ah you've found the widget my friend' Response 2: ‘You must find the widget my friend'
Let's try this
Add a new variable called MetVilla to the top of the Quest Script (under the quest data tab). We should declare any variables used by the quest in the Quest-type script.
SCN BGM001QuestScript Short DoOnce1 Short MetVilla Begin GameMode If (DoOnce1 == 0) AddTopic BGMMessage4U Set DoOnce1 to 1 EndIf End
This variable will be automatically set to zero. We can use the response result box to bump this up to one after the speech with a bit of script. Add this in after "AddTopic BGWill".
Set BGM001.MetVilla to 1
Don't forget to click the compile button!
Summarising the first response:
|ADD TOPICS||No add topic|
AddTopic BGWill Set BGM001.MetVilla to 1
We can then add this alternative response info to the GREETING topic:
|RESPONSE||"Whenever you want to talk about your uncle's will, let me know."|
|ADD TOPICS||No add topic|
|RESULT SCRIPT||No script|
The first time we greet him he gives the longer speech, the second time a shorter one.
We can now add response info to the BGWill topic.
Try this one yourself using this summary to guide you. Don't forget the quest bump script. You will need to add a new topic called BGHubart.
|TOPIC TEXT||"My uncle's will"|
SetStage BGM001 20
Again we have a stage bump, this time to stage 20. In the Quest Stages tab, add a journal entry for stage 20.
I've been told that I may have inherited some property from my late uncle, but the courier carrying the details has gone missing. I will need to go to Chorrol and speak to a Captain Hubart of the Chorrol Guard to get more information.
We will also add a Quest Stage Result Script.
But first we need to create a prop letter, so we can refer to it in the script.
Again we can create a new item from scratch, but it means trying to add artwork to the game. Unless we want the letter or scroll to look completely unique, and have some talent in that direction, it is a chore we don't need to do.
Instead, select any letter from the Items->Book list in the object window, change its ID to something meaningful like BGHubartLetter.
The text on the right hand side indicates the content of the letter. We can edit this. I will look at the precise details and syntax needed to produce text in another lesson. It uses standard HTML tags. For now, the key command is <br>, which produces a 'line break' or 'new line'. The font face can be left alone.
<font face=5><br> Dear Vilanus, <br> <br> I regret to inform you that the White Horse courier Janus Jakobs, who you asked me to meet, has not arrived for her expected rendezvous. I know you were expecting some important documents to arrive.<br> <br> I don't have enough man power to launch a search; perhaps you could find someone willing to assist me in finding Jakobs? <br> <br> I look forward to hearing from you, old friend. <br> <br> Yours, <br> Captain Hubart
Save the letter, AND MAKE SURE YOU CLICK 'YES' TO CREATE A NEW FORM.
Now, type this in the results script box for stage 20:
Player.AddItem "BGHubartLetter" 1
Then click the "Compile Result" button.
We can also add a new response info to the topic called BGHubart, to direct the player to Chorrol:
|TOPIC TEXT||Captain Hubart|
|RESPONSE||"You’ll find him in Chorrol."|
|ADD TOPICS||No add topic|
|RESULT SCRIPT||No script|
Try this for yourself. You can always refer to the PLAYTEST version if you get stuck.
We have completed phase one. You should stop to test everything out before moving on. Just test a few conditions to make sure that everything is working, and that you haven't made any small mistakes.
Chorrol Phase[edit | edit source]
In this phase of the quest we want to use a new NPC called Captain Hubart to direct the player to solve a mystery. He will direct the player to a cottage, where they will discover a mysterious medallion and the dead body of the courier. Hubart will then be able to help us move on to Aleswell and the next phase.
For this phase, we will need to create:
- NPC Captain Hubart
- NPC Dead Courier
- NPC DummyPlayer
- A document
- A medallion
- A cottage to house courier.
Again, we need to add the NPC first so we can reference him in conditions.
As always, we could use a new NPC object, but it really saves a lot of time and effort if we simply change the name and ID of an existing one. This time we can just copy a Chorrol Guard NPC, such as ChorrolGuardPatrolNight01. Change the ID to BGCptHubart, and save it as a new form.
Strip out the AI, but leave his inventory as is, since the Chorrol guard's inventory already contains all we need. We can also leave the factions alone. I placed Hubart outside the Fire and Steel shop in Chorrol (worldspace ChorrolWorld).
Hint: a fast way to get to an exterior cell is to select the interior cell, and then click on the teleport marker by the door.
This is only his starting position. We can add AI packages later to move the character about.
We have to set up a new response to the BGHubart topic.
We could add a new topic but it is always a good idea to try to limit how many new topics we add. This reduces the ‘footprint' of the mod, and helps avoid possible conflicts with other mods.
We want to set up a response so that when any Chorrol based NPCs are questioned they will direct the PC toward the likely location of the captain. Add conditions to limit the race to human again (saving all that MP3 work), and the location to the Chorrol dummy cell (thereby including all cells within Chorrol). We can also limit the ‘timescale' to the current quest stage (20). Try this yourself. You can always refer to the PLAYTEST version if you get stuck.
|TOPIC TEXT||"Captain Hubart"|
|RESPONSE||"He's usually on duty near the Fire and Steel."|
|ADD TOPICS||No add topic|
|RESULT SCRIPT||No script|
We can now add some dialogue for Hubart himself.
The first can be attached to Vilanus Villa topic, to reduce the ‘footprint'.
First, add a TOPIC called BGCourier.
|TOPIC TEXT||"Missing courier"|
|RESPONSE||"Vilanus has sent you to investigate the courier's disappearance?"|
|RESULT SCRIPT||No script|
Stop to test this out, and then refer to the PLAYTEST version if you are stuck.
Before we go any farther, we need to set the scene at the cottage.
Locating the Cottage[edit | edit source]
If you are using BGModTutBase.esp, you can use these cells: BGModCourierCottage in the Interiors world space, and CourierCottageExt in the Tamriel world space. The exterior building that matches the cottage is LeyawiinHouseLower03, and the door is LeyawiinLowerLoadDoor01.
The cottage could be located anywhere in Tamriel. I think I've looked at just about every cell in compiling these tutorials and working on my mods. When selecting the location for this cottage, I took into account several factors. I wanted it to be West of Chorrol. I wanted it to be close to the main road. I knew I couldn't go too far as the road abruptly ends by a cliff, marking the edge of the world space. I also decided to use the game to give me a little bonus or two.
Around this location, is a dungeon with some external guardians, some bandits and an oblivion gate. This means any NPC will be harassed by bad guys that we don't have to work too hard to create.
We want to set the internal scene in readiness for the PC's arrival. I have used a copy of the White Stallion Lodge as a base. We want to customise this. Again we can work on this in more detail when we polish the quest prior to release.
We want to remove some of the clutter. We also want to give the impression a fight has taken place. Tips some chairs and tables over (Y=90). Remember this set will be locked at the start and you will only use it for a short time, so don't go overboard. We also want to place some props. We need an amulet to trigger the next phase. Why an amulet? It's small enough that you have to look for it, but not so small that it becomes hard to find. Copy an existing item of jewelry from Items->Clothing->Amulet as a base and edit it. Change the ID to BGEmbossedAmulet. Check off the Quest Item box. The player can not drop or sell quest items.
We also want to create a custom letter called BGPartialLetter. Set the letter as a quest item. We will refer to it in some scripts.
<br> <font face=5><br> Dear Vilanus, <br> <br> The client wishes his only living heir in Cyrodiil to inherit his house. I have enclosed the deed and key. The location of the house is registered at the Imperial City Land Offices...<br> <br> <br> <br> LETTER IS RIPPED HERE <br> <br>
Of course it would look really cool if we could create a custom texture for a torn scroll, but that is beyond the scope of this tutorial.
Finally we need to place the body of the unfortunate courier.
Bodies are NPCs who just happen to be dead. You will need to create another NPC. Use Courier1 as the base.
Place this character in the render window, set its ID to BGDeadCourierRef, and position the corpse in a suitable place. I put her in a side room so you don't see her right away. I also left a nice blood trail to lead you to her. Initially, the NPC will be standing up.
Next click Edit Base to open the NPC window. Change the NPC's ID to BGDeadCourier. Edit the NPC's health to read zero (0). (To access this stat, uncheck the PC Level Offset and Auto calc stats boxes.)
Now, the awkward thing is the fact that she is just standing there. She will stay standing in the game unless we make her fall first. To get her to fall, click on the WORLD menu and select Run Havok Sim (with the bouncing red ball). Down she goes.
We can now drag her about to get the position right.
I also placed a sword which pointed directly at the amulet.
Next, we have to add the letter to the dead courier's inventory. Open the NPC window for BGDeadCourier and click on the Inventory tab. Then drag BGPartialLetter from the objects window over into the inventory list. You will be warned that the letter is a quest item. Just click OK.
Another useful technique is to create an NPC called something like BGDummyPlayer. We will not place this NPC in the world, so don't bother to edit anything other than the object ID.
We can now set the ownership of the door and cell (Lesson 3) to BGDummyPlayer. This means that all items in the cottage will display the red hand, with the exception of the embossed amulet. This is a handy way to set ownership without having to create detailed NPCs. We can use BGDummyPlayer to set the ownership of all the doors and sets we want to prohibit our player from entering.
Now create a key called BGCourierKey. Select an existing key and change the editor ID. Also check the Quest Item box. Edit the cottage door to set its lock status to "Needs a key", and use our new object as the key.
We need to add two other items to the cottage.
We will find these under the Static Objects.
Drop an XMarker or an XMarkerHeading object inside the cottage and give it a reference name like BGCourierLodgeXMarker.
Now select a MapMarker and drop it just outside the cottage door, in the exterior cell. It looks a bit like a door teleport marker, but it's pink rather than yellow.
Edit its details to give it a reference name like BGCourierLodgeMapMarker.
Open up the MapMarker Data tab, check the marker data tick box and select settlement. Theses flags control what type of icon appears on the players map.
Finally in the name box call it Courier Cottage. This is the name that will appear on the map.
We need to add a bit of script to enable it. First we need to add a bit more conversation.
Add stage 30 in the stage tab, and create a topic named BGCluesFound (which we won't be editing just yet). Then create the following topic.
SetStage BGM001 30
Add one more response to this topic in case the player tries to talk to Hubart again after they've been given the key to the cottage, but before they've found it.
"Did you check out the cottage?"
|ADD TOPICS||No add topic|
|RESULT SCRIPT||No script|
Now in the stage tab for stage 30, add this to the journal:
Hubart told me that the courier sometimes stays in a small cottage just west of Chorrol. He marked its location on my map and gave me a key to the door. I should go check it out.
And add this to the stage result script:
Player.AddItem "BGCourierKey" 1 ShowMap BGCourierLodgeMapMarker
This gives the player the key to the cottage and activates the map marker.
The syntax for the ShowMap Function is
ShowMap MapMarkerID, enableFastTravel (optional)
The MapMarker ID is the reference id for the map marker. The enableFastTravel is an optional parameter which takes the value 1 if you want to be able to fast travel immediately to that location.
If enableFastTravel is not given (or set to 0) then you can not fast travel to that location until you've found it once.
We still need to add all the quest targets, and we'll use the XMarkerHeading for that.
Up 'til now we have been using dialogue to control progression, but now we need to begin using scripts more continue.
In Lesson 7 we will complete the quest and focus on SCRIPTING.