Quest Guidelines

From Project Tamriel Wiki
Jump to navigation Jump to search

Reference and guide for making quests in Morrowind.

Quest-making is one of the most approachable parts of Morrowind modding and a good place to get started.

In addition to reading this page, make sure to also check the editor-specific tips and pitfalls on the Construction Set Tips page!

Tutorials

Showcases

As with all prospective developers who intend to work in the Construction Set, quest developers need to pass a showcase prior to claiming quests in Tamriel Rebuilt and Project Tamriel. This is not a test; you don't need to get it right the first time. Instead, we will give you feedback and help you learn how to produce quests that fit into our project.

Before posting a quest showcase, please make sure you are familiar with the contents of this page, as well as the Writing and Dialogue Guidelines and NPC and Creature Guideline. All showcases must specifically adhere to the requirements listed below in this section.

In some cases, you may wish to implement an unclaimed quest as your showcase. You can find these quests on the Tamriel Rebuilt claims browser or the the unclaimed quests forum of a Project Tamriel sub-project. Note that you should pick a relatively simple, miscellaneous quest. If you wish to do so, please inform someone by posting on the forum or Discord chat.

Once you have made a showcase in the Construction Set, post the .ESP file on the Showcase Forum – either on the Tamriel Rebuilt or Project Tamriel website, depending on where you want to work primarily. Add a brief description of the quest as well. You should post exactly one showcase thread, even if you also want to make interior or exterior showcases.

If your showcase has not been officially reviewed or it seems to be taking a while, please bump the thread as a reminder. Sometimes we forget!

Requirements

  • Location: Anywhere in TR, PT or PI. Quests that take place entirely or mostly in vanilla areas (Vvardenfell, Solstheim or Mournhold) are not eligible for the showcase.
  • Conventions: Must use correct TR_Map ID (for Tamriel Rebuilt; Project Tamriel has its own equivalent location IDs) for NPCs/Scripts/Journals
  • Journal: 6+ stages.
  • NPCs: Add 3+ NPCs or Creatures, 2 of which have speaking roles. If you are implementing a quest claim for your showcase and NPCs are already implemented, this requirement can be waived.
  • Topics: Add 1+ topic, and edit at least a greeting and latest rumors.
  • Scripts: Must use at least 2 of: [Positioning, timers, AI Packages, item handling, death].
  • Script Variables: Must use Tamriel_Data and give NPCs correct default scripts, or ensure TR NPC local variables are set.
  • Size: Aim for 15-20kb. Must not be greater than 70kb in size.
  • You have used the Standards Validator and fixed all of the issues it reports.

We look to make sure that:

  • Dialogue in game is appropriate to the situation,
  • Journal progress is recorded, and the quest progresses when the right conditions are met,
  • The quest closes correctly when completed,
  • The plugin (.ESP file) is clean – see the respective section below.

Your scripts must:

  • Trigger correctly,
  • Work efficiently,
  • Terminate correctly,
  • Not affect framerate,
  • Be properly formatted.

Don't worry if you don't hit those targets on your first few tries. We will help you improve the showcase and gain the skills needed to make good quests.

Location

If you aren't implementing an existing quest claim as your showcase, you can come up with your own quest outline. If your showcase is accepted and meets all the requirements, there's a high chance that your quest will be merged to one of the province mods proper.

As mentioned in the previous section, you are allowed to set your showcase in any of the Tamriel Rebuilt, Project Tamriel and The Padomaic Isles areas, both released and unreleased, however to maximize the chances of your quest being merged and to minimize the amount of work needed to adjust it before it can be merged, we currently suggest that you pick one of the following locations:

Quest Claim Workflow

General ideas for quests for a certain settlement, region, or faction are often brainstormed in Discord discussions. Sometimes, these ideas are posted on the TR implementation forum or in the asset browser, but more often directly on the TR claims browser or the respective quest claims forum on the PT site. Once implementation of these quests begins, quest developers are expected to write the dialogue and journal entries for those quests and to implement it in the Construction Set. In rare cases, the dialogue may already be written, in which case it is the quest developer's task to implement the lines in the Construction Set, while still being expected to make needed changes to the dialogue.

Below is a proposed workflow for making quests. It does not matter in which order you do things, as long as everything comes together at the end. Some people choose to write dialogue for a full questline up front, then implement it in the Construction Set; others will add dialogue directly in the Construction Set and implement as they go.

Getting Started

  1. Find a claim that you want to work on. These can be found in the Tamriel Rebuilt claims browser or the Claims > Quests subforum of the respective province in Project Tamriel.
  2. Hit the "Claim" button and post a comment on the claim page, asking to claim it. A senior developer will come along a grant it eventually. If you want this to happen faster, also post this on Discord.
  3. Download needed files:
    1. The official release of Tamriel Data, which contains the new assets used by PTR.
    2. The updated in-development Tamriel Data including the loose files and Tamriel_Data.ESM from GitHub (click on the green Code button, then Download Zip).
    3. The latest version of the province's main .ESM file.
      • For Tamriel Rebuilt, you can find them on the Release Files tracker. The main file is TR_Mainland.ESM. On each section file page, the lowermost files on the left-hand-side column are what you need.
      • For Project Tamriel, the main file will be on the forums, in the respective provinces' Private > Internal Files forum. You will only be able to access them if you are a Project Tamriel developer. If you aren't a developer yet, but want to make a showcase, ask on Discord for access.
    4. The section files relevant to the quest (in the same locations as the above).
    5. In some cases, the claim page will already contain a work-in-progress file. If so (and unless specifically instructed not to), you can use this as a base to work off of.
    6. Optional: For making playtesting easier, we also recommend downloading Templates for Playtesting, which allows you to choose from among a variety of classes and levels, or even start as a vampire, so you can test multiple possibilities easily. Do not load this in the Construction Set; only when playtesting in game.
  4. Set your load order:
    1. Morrowind.esm
    2. Tribunal.esm
    3. Bloodmoon.esm
    4. Tamriel_Data.esm
    5. [Project Main File].esm – e.g., TR_Mainland.esm for Tamriel Rebuilt, Sky_Main.esm for S:HOTN, or Cyr_Main.esm for P:C
    6. [Section File].esm
    7. [Your own quest].esp – set this one active; it's where all your scripts, journals, dialogue, and NPCs will go.
  5. Read the claim description carefully. This is important since you are not making just a personal quest mod; all quests need to fit in with those around them, and the requirements and restrictions listed in the claim page are written to ensure that.

Writing

A significant portion of quest development is simply writing. It is the main way through which information is passed to the player, and is important to get right.

Make sure to adhere to the guidelines given on the sub-page Writing and Dialogue Guidelines, especially regarding style; it can be jarring to see a quest with a significantly different writing style than the vanilla game.

  1. (Optional) Create a separate text or spreadsheet file for your writing. While not strictly necessary, this makes a proofreader's job much easier when it comes to catching grammar or lore mistakes. For example, Google Docs and Google Sheets are easily shareable and free to use.
  2. Write an outline for your quest. Even if the main thrust of the quest is given to you already in the claim description, it is helpful for you to break the quest down into smaller tasks or chunks.
  3. Write the journal messages. These provide the backbone for your quest, tracking its progress and helping nudge the player to the right path.
  4. Write all needed topics and greetings.
    • A single quest typically has one main topic – this helps the players know which topic to hunt for to progress the quest. You may of course have side topics, too.
  5. Proofread your writing. Use your separate files, or if you have already created text directly in the Construction Set, you can also create a text dump from the drop-down menus. Alternatively, Tes3cmd will generate a text file of dialogue with the command tes3cmd dump "Data Files\MyPlugin.esp" -type info > blah.txt – this will create a file named blah.txt with a dump of your dialogue. It is often helpful to have a proofreader check your work before you start putting the dialogue into the game – ask for help on Discord.

Implementation

For implementation, an important thing to keep in mind

  1. Add needed NPCs. Make sure to adhere to the NPC guidelines.
  2. Add needed items.
  3. Implement the journal stages.
  4. Implement needed dialogue.
  5. Finally, tie it all together with scripts. Often the results box of the dialogue entries is used to run small mwscript commands and progress the quest.

Quality Control

  1. Playtest your quest. It is an absolutely crucial part of quest development, helping you catch the inevitable bugs that creep in and the corner cases you hadn't thought of. You should aim to implement your quest in stages, so that you could test different parts as you go. Make sure to test both in the original Morrowind.exe engine (more important) and OpenMW (more convenient, but not as critical, since OpenMW is actively aiming for full compatibility with quests designed for Morrowind.exe). It is always good to ask other people on Discord to test your quest, even while development is ongoing. They will catch things that you miss and will come at the quest with different assumptions and play styles than you have.
  2. Run the Standards validator. This is a very useful program to catch deviations from standards imposed in Tamriel Rebuilt and Project Tamriel. See the prior link for usage and install instructions.

Documentation

It may be difficult for the playtesters and reviewers to wrap their heads around your quest. To help with that, make sure you provide documentation on:

  • the meanings of any global variables you use,
  • the character you have given to an NPC in a comment under this NPC's "Background" response (i.e. in the result script; use a semicolon ; to start a comment),
  • uses of control and controlQ,
  • whether your quest can kill the character or render him untalkative (unless it's a _q_ character made for your specific quest),
  • how to play the quest (i.e., a walkthrough), particularly as to how to start the quest and what statistics (speechcraft, charisma etc.) matter,
  • if it's an n-th quest in a larger quest line, explain how to quick-start it without running through the whole questline (e.g., which journal stages to enable in the console),
  • weird hacks like the use of non-breaking spaces to prevent topic linking,
  • if there is something subtle going on that only attentive players will spot (e.g., one character is playing the player for a fool and it's never explicitly explained, or some character is secretly Talos).

General Guidelines

  • Keep Construction Set IDs consistent! I.e., if you quest ID is TR_m4_Om_Statue, then any NPCs, items or scripts you add should ideally also start the same way. For example, you might give an quest-specific bowl the ID TR_m4_Om_StatueBowl. This will help reviewers and future generations of Tamriel Rebuilt or Project Tamriel modders figure out why and where certain items were added. Note, however, that you do need to keep all IDs unique. This is checked automatically in most cases, but not for Journal and Script IDs, so you will have to ensure that for yourself. See the ID Guidelines for more details.
  • If making a faction quest, put the faction in the quest title. E.g., if you are making a Fighters Guild quest, it should be called "Fighters Guild: No Sin Goes Unpunished" instead of just "No Sin Goes Unpunished."

Design Principles

Morrowind is a game that revels in the mundane – its quests are quite often short and to-the-point, technically uncomplicated, and involve the small and mundane concerns of various middle managers. This is different from the more showy quests of TES IV or TES V, but it is this game's signature and perhaps even its strength (it certainly helps roleplaying). Accordingly, Tamriel Rebuilt and Project Tamriel should attempt to make most of their quests mundane in the same way that the vanilla game does.

Hence, the fundamental structure of most quests should be:

  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.

However, it is undeniably interesting to have some outliers here and there – highly complex miscellaneous quests with branching choices, long and involved narrative-driven questlines, and so forth. Still, that shouldn't be the norm or the expectation – not only for adherence to vanilla standards, but also for practical reasons (e.g., overly complex questlines were initially planned out for Tamriel Rebuilt's Dominions of Dust release, resulting in a years-long bottleneck in questing).

What to Watch Out For

  1. Be very wary of making your quest too complex. It is incredibly easy during quest design to write something that sounds good on paper, but is a nightmare to implement or review. This is the main reason we are now requiring our quest writers and designers to also implement them in the Construction Set. Think whether the effort for a complex sequence is worth it for the player; often it is not, since you could have spent the same amount of time on making two or three somewhat simpler quests instead!
  2. Although combat is the core gameplay in Morrowind, and should feature often in quests, it can be a little boring. Woosh woosh hit woosh woosh hit. Repeat until insane. Apart from the fight against Dagoth Ur and Lorkhan’s heart there aren’t any real boss fights in the vanilla game. Fighting Almalexia/Imperfect/Hircine was about as fun as fighting a cave rat with 2000 hitpoints. Ideally, there should be at least some other aspect to a kill quest – e.g., sending the player to a cool location, giving dialogue to the kill target to explain the conflict, etc (see below).
  3. Fetching things is also a core part of Morrowind questing, but on its own, it is not particularly fun. Being sent half the world away to find a missing item is tedious work. It doesn’t matter if the item’s a shipment of Sujamma or a lost artifact. Try to add something else to the mix in fetch quests.
  4. Escorting NPCs through the wilderness is fraught. It should be done occasionally, but care must be taken to avoid making the NPCs path too difficult. In the vanilla engine, the biggest challenge is oftentimes provided by the AI (or lack thereof) – make sure this isn't the case in your quest. Here, playtesting is essential.

A Few Things That Are Fun

  1. Exploration. Discovering interesting/pretty places.
  2. Conspiring. Lying to NPCs and being lied to by NPCs.
  3. Solving puzzles.
  4. Getting meaningful rewards. Not just gold.
  5. Getting the impression that what you do has meaning. Have the NPCs react differently depending on different outcomes. After succeeding in a difficult quest you should be the talk of the town.
  6. Witnessing showy scripting. The world of Morrowind is very static, so whenever a quest offers something cool and new to see, it’s a reason to play the quest in itself. Think teleportation magic, NPCs engaging in combat with one another, water levels rising, walls moving, lights going out, spells exploding, sound effects, etc..
  7. Making choices. A pivotal moment where the player gets to make a choice in what direction the quest will go from there on out. Do I kill this person, or let them live? Do I address this important character politely, or insult them? Also, since there’s no proper “infamy" counter in Morrowind, failing quests/being an evil character should be recognized via dialogue responses.
    • Watch out, though – choices can make the implementation of a quest exponentially more difficult, especially if they occur in the middle of a questline. Often, given X amount of time, a developer can either make three simple quests, or one quest with two branching choices. It is not at all clear which of these options the average player would appreciate more.

Good Examples of Complex Quests

  • Dead Marshes in Tamriel Rebuilt – Combat made fun with simple puzzle-solving. The lich Sabine is nigh-impossible to kill unless you kill her husband Reynard first and smash Sabine’s Locket.
  • Search for a Perfect Sword in Tamriel Rebuilt – Fetching things made fun with meaningful rewards. After finding and giving ‘the perfect sword’ to Anirwen he will become a follower for the player.
  • Coladia Nelus' Stalker in Tamriel Rebuilt – Escorting made fun with conspiring / puzzle-solving. The player escorts and betrays/traps the stalker to either in a Velothi tower or a ship. This quest also features some showy scripting.

That being said, most quests absolutely should not be as complex as the ones listed above! For better overview on how to work with complexity, in this section you have this problem explained in more detail.

Starting a quest

TES III allows the player to either explicitly refuse or accept quests, without having their journal be polluted by stuff they have no interest in. Although this is not always strictly enforced in vanilla, we keep to these tenets:

  • The player should always know when they are accepting a quest.
  • The player should always know when they are refusing a quest.
  • Clicking a topic or choice is active consent to either one.

Hence, do not start a quest on a greeting, nor based on proximity to something in the game world.

Complexity problem in better detail

When dealing with questline or miscellanous quest, it is very important how its complexity affects both your development process and then difficulty of later review.

Branching

 
Different quest designs

In the graph on the right, the quest design shown on the very left is obviously the least complex quest possible. You hit every stage one after the other, and you know exactly what has happened previously at every given moment. So even if your quest involves eight NPCs who each have some new dialogue for every single stage (not that they should, but hypothetically), there is no increase in complexity, just more writing and proofreading effort. In this graph the quest has six stages, but more realistically, a quest like that probably has just two or three. "Deliver this letter to X and come back" or "kill Y and come back" or similar. Obviously there's a limit to how many quests like this you should make, but there is always room for more quests of such kind. Good dialogue can make what's mechanically trivial engaging.

The second design is a more realistic format for something with this many stages. Some steps are optional. Maybe you're first sent to question someone else as to where your target is, but if you go straight to the target that gets skipped. Or maybe you're sent to collect an item from someone, and they set you a sub-task before they give it to you, but if you kill them you can take the item straight away. As long as all paths lead forward this usually doesn't increase complexity by a lot. Problems here usually arise when the player is not prevented from retroactively doing a step they've already skipped, such as having stolen an item but its owner still setting you a task to do in exchange for the item.

The third, with the multiple branches, is a good illustration for a linear increase in complexity. Obviously this is much more work, as you're essentially making three quests at the same time. However, if the player is rigidly locked into one path (after having been given a proper choice, of course), the increase in work stays at 3x. Similarly, if the entire quest is "cinched" together at the end, it does not create a cascade of complexity later on. You can still have the occasional dialogue entry either filtered to 110 or 100 to refer back to something that happened earlier, but in this model this would be entirely for flavour. This graph also includes failing the questline as an example of consequences that don't significantly increase complexity - if there's no follow-up quests, there's nothing to worry about. This should still only be done selectively, because it rarely is rewarding from a gameplay perspective. Either you're obviously doing an idiotic thing, in which case no one will do it (except to reload), or you're doing something that seems more sensible, and then you might get frustrated that it locked you out of a questline.

Finally the rightmost design is the (somewhat hyperbolic) worst-case scenario in terms of complexity. You have two branches, but instead of forcing the player to do one or the other, you allow them to work on both and switch around between them. You get sent to get someone arrested, but the target pleads with you to spare them and lie to the questgiver, but you can still pick up the contraband in their house and tell the guards, but you can also still accept a subquest from their neighbour to make them wrongly implicate your target in a crime, but you can also still just kill them... and so on, until every conversation and script you have needs to account for six edge cases. And critically, six edge cases that almost no one will ever get to, because most players will want to pick a path through the quest and stick to it, and them jumping between paths is most likely on accident because they explore and exhaust every option. That doesn't mean you can never do this, but it needs to be worth it. Changing your approach after you've been presented with very significant new information is one thing, but you don't need to create plot knots that let your player change what they've already commited to arbitrarily. And the thing about the questline ending with different outcomes carrying on into future quests is pretty self-explanatory. Unless there's really two completely different quests that follow and that then join up at the end (or are the end of the questline), but that's a lot of extra work and would be something that happens very rarely.

These scenarios are an exponential increase in complexity. Going through all the branches and making sure that all the silly edge cases work takes much longer to make, playtest, and review than several linear quests would do. Which, again, is not to say that you can never do this. But a questline with quests like this should be, like, one-per-release.

Reducing complexity

Here are example ways through which you can reduce complexity while preserving its fun factor. Those suggestions below are meant mostly for questlines, but can be useful guidance also for miscellaneous quests.

  • Split large sequences into multiple quests and add natural breaks. Instead if a preparation + return + action quest, make a preparation quest, some other quest or a rank lock, then an action quest. Try to keep each quest restricted to a single objective
  • Don't reveal certain parts until later quests. For example, if your questline's ultimate goal is to find a certain item, obtaining it too early won't break the questline if the questgiver doesn't know or tell you about it until the final quest
  • Involve less NPCs where possible. For example, instead of sending the player to someone else for information, make the questgiver say "X told me Y", which reduces the amount of stages and rids you of handling the NPC's death
    • Do not use this rule everywhere - some quests should have searching for information as their main objective. A good example of a situation when an informant's death creates a different outcome is the Alof and the Orcs quest in the Balmora Fighters Guild.
  • Pay more attention to global events, history or things that happened before the game instead of events that you want to occur during the game.
    • Combined with the two previous points, it allows you to remove a lot of artificial limitations to the player's freedom, such as killing important NPCs early on
  • Rely on existing game mechanics instead of scripted sequences. Multiple ways to reach one target may exist without any scripting or using journal at all.
  • If quest Y depends on quest X outcome, keep quest X linear and allow branching only in quest Y
  • If you can't cover all aspects of your theme in one questline, leave certain parts to miscellaneous quests, other factions or other questgivers of the same faction. Quests shouldn't be isolated from the outside world.
  • To make your quests more narratively engaging while keeping them simple, certain dialogue may unlock side topics describing more specific details. For reference, see the Almas Thirr FG, Anvil MG, or Old Ebonheart EEC questlines.
    • Avoid using too many side topics - if they're overused, your dialogue may lose its brevity and distract you from the main objective. An example of quests that overuse new topics is King Helseth's questline
  • Don't overthink your narrative. Despite that telling a story is one of the main goals of each quest, in reality many players will be too consumed in exploration, fighting and other active quests to keep track of all its details. Sometimes, focusing on a fun location, item, or character is more important than providing a deep narrative explanation for interacting with them.

NPCs

Most quests will involve creating new NPCs. When doing so, make sure to adhere to the NPC guidelines.

It is often a good idea to involve some already existing NPCs (those added in an NPCing claim) in your quests. If you do so, make sure to ask on Discord or check on the claims browser whether that NPC is already involved in another quest. If so, you will have to figure out a good way to avoid conflicts, or pick another character instead.

(Ideally, for each release area, we'd have a spreadsheet listing the NPCs and their involvement in quests. This is not yet the case for most of our work, but may soon be.)

Markers for moved NPCs

Often quests will involve moving an existing NPC from one location to another (for example, someone being arrested and ending up in a prison cell). While an NPC that just starts out as disabled plainly shows up if you look at their cell in the Construction Set, there is no automatic indication for where a PositionCell command will deposit an NPC originally placed somewhere else.

This is a problem, because if you today create a quest that moves an NPC, another dev might (possibly years later) look at that cell, not know about your quest, and put something else there or even make the spot totally inaccessible as an interior gets redone. So we have to manually add our own marker.

NPC markers are found in the Book category of the object window. They are the same markers that can be used during interior/exterior design to act as placeholders, but unlike them, markers that show NPC movement do not get removed as locations get finished, but rather stay there forever. This is how the object looks like and is placed:

 


1. ID and name: Every such marker has a unique ID that follows the same format - in this example TR_m7_MARK_HH_Othmura_slave. The TR tells you that it's part of Tamriel Rebuilt, the m7 that it's in Map 7, MARK that it's an NPC marker, HH that it's in Hlerynhul, and Othmura_slave is a short descriptive term for which NPC it refers to. The Name field is just slightly more descriptive.

2. Book Text: Here is where a longer description and further details go. It tells you which NPC is the one being moved, so it's easy to find them in the NPC tab. And it tells you where the exact PositionCell command that makes the move happen is triggered (in this case a script, but could be a dialogue result too), so someone in the future can easily go there and tweak the coordinates if the placement needs to be changed. Note that this doesn't use the markup required for making the text actually legible in-game (which you couldn't anyway, since there is no way to "obtain" this item), because this way it's easier to read in the CS. The validator now comes with an exception to ignore unreadable text if it's in a book item that has the tr_editormarker_npc.nif model.

3. Model/Art File: Make sure that your marker has tr_editormarker_npc.nif set as its Art File. You shouldn't ever have to do this manually, just grab an existing marker, change its ID and save it as a new object. This will make it appear correctly when placed in the CS, and also tell the validator to ignore issues that would usually be flagged.

4. Placement in the Render Window: This is simply placing the new object in the location the NPC will appear in. This doesn't have to be exact down to the coordinates, just close enough to clearly show that this spot will be occupied.

After the marker is placed, also add its ID as a comment to the script or dialogue result where the PositionCell occurs. Don't forget to place a ; in front of it, so the game knows that this is not a command to execute.

 

Journals

Journal messages form the backbone of the quest, allowing for progression and helping remind the player what they need to do next.

See the ID guidelines of the on what to name journals in the Construction Set; this depends on the project you are working on. E.g., for Tamriel Rebuilt, a quest will be named TR_[map]_[Faction initials if any]_[Settlement initials or "wil"derness otherwise]_[Quest title or Faction questgiver], like so: TR_m3_OE_Foeburner.

The game keeps tracks progress by remembering the journal stage as a simple integer. All journal messages are associated with a certain stage (index); you give them to the player by invoking the mwscript line so: Journal TR_m4_Om_TheStatue 10. Keep in mind that the journal stage can only increase, never decrease. Hence, journal stages should be numbered in an increasing order as the quest progresses. Often you will check how far you are in a quest by comparing the present journal stage with a number in either a script or a dialogue filter.

The first Journal entry will be the quest name shown in the player's in-game journal. It needs to be marked with the stage 0 and have the "quest name" tickbox checked.

Good Practices for Journal Messages

  • During initial design, number the Journal stages in tens – 10, 20, 30, etc. This is because you will inevitably have to add more Journal messages in between during development, and this gives you space to do so.
  • Journal stages that mark the completion of the quest should start with 100, or in complex quests where your normal stages go above 100, you can have them start with 200, etc.

To make more complex or branching quests work, it is often cleaner to have several different journal IDs under the hood for a single quest, so that the game could track progress on different branches/tasks separately. E.g., TR_m4_Om_Statue for the main part of the quest, then TR_m4_Om_StatueA for one branch, and TR_m4_Om_StatueB for another branch. Make sure they all start the same way, so when other developers search the Journal list, they will find these listed side-by-side. If you give all of these branches the same quest name ("The Statue" in this case), the journal messages will be listed under single entry in the player's in-game journal. Also, keep in mind that when you mark a Journal message in a branch as "completing" it, then the Journal messages under all other branches of the same quest will be moved to the completed quest list in the player's in-game journal.

You may also add dialogue/journal entries to account for NPCs being dead ahead of time, although this is not a requirement.

Situations where you should take the NPC being dead into account:

  • NPC is hostile
  • NPC is the kill target of another quest (including MT assassination)
  • NPC is in an "evil" faction and could reasonably be killed by the PC (Camonna Tong, slavers)
  • NPCs who are involved in combat
  • NPCs who become followers

Situations where you can, but don't have to. Up to your personal preference:

  • The quest-giver, if the quest is a misc
  • NPC is very important (King/Duke/Lord, etc)

Situation where it is best not to bother, either due to bloat or just infeasibility:

  • The quest-giver, if the quest is a faction quest

See also our journal-specific writing style guidelines.

Topics

The dialogue system in TES III relies on topics, which are filtered to various locations, NPCs, Journal stages, etc.

Main Topic

Most quests come with one or, less often, several main topics which act as a focal point – the player knows that to progress in a quest, they need to speak on that topic with other NPCs. Ideally, your important characters would have Responses befitting all different stages of the quest. A good rule of thumb is to have a Response for each of these general stages:

  1. When the player first asks the questgiver about the quest.
  2. If the player rejected the quest.
  3. When the player has accepted the quest and the quest is still in progress.
  4. When the player returns to the questgiver for their reward (quest completion).
  5. After the player has completed the quest successfully.

In addition, topics unique to a quest should ideally be found as hyperlinks in the quest’s Journal entries, so that the player can easily check the dialogue relevant to that quest. So a Journal entry for a quest should read “Rathog gro-Mullug in Narsis docks asked me to help him settle his debt with Rethys Naaril, a Camonna Tong enforcer. I should look for Rethys Naaril in the Black Hearth Cornerclub.” instead of “Rathog gro-Mullug in Narsis docks owes some money to a Camonna Tong enforcer named Rethys Naaril and asked me to help him settle the debt. I should look for him in the Black Hearth Cornerclub. [no hyperlinks]”

Keep Topics Unique

Most important, when you’re implementing a quest and need to create a new topic, is to make sure that topic is unique! If your topic is something simple, there’s a chance that it will conflict with another plugin adding a topic that incorporates the same words. Should that happen, the topic text won’t be highlighted in dialogue. Using the exact same topic name as another plugin is not a source of conflicts in and of itself.

Note: If two plugins edit the same dialogue line from the original game to add new dialogue under or above it, the ordering may end up reversed when both are loaded together. This is one of the reasons why adding dialogue above the top lines of the original game (or under the bottom lines) is discouraged. However, this won't happen if your plugins are clean and don't edit vanilla dialogue.

A prime example is the “help me” topic that two TR quests used in the past. This topic was also used within an LGNPC mod, which was not an issue, but yet another LGNPC mod added the topic "able to help". It so happened that in TR, the greeting meant to hyperlink "help me" included it in the sentence "perhaps you could be able to help me". Because of this, when both mods were loaded, the game engine looked for "able to help" instead of "help me" and the player was unable to click the topic. Therefore, it is important to make sure that quest topics you create are unique and even more important to use AddTopic so the player can continue the quest even if there is a conflict. This is especially important when factoring in the other province mods and realizing that there are going to be a thousand or so new topics.

A more or less idiot proof way of making sure a topic is unique is to have it contain a proper noun: a quest location or an object or a NPC relevant to the quest. So, for example, instead of ”Will you help me settle my debt with Rethys?” one could use “Will you help me settle my debt with Rethys?”. This will make sure that your plugin does not generate conflicts elsewhere. If another plugin uses the topic "settle my debt", though, the same issue could still apply in yours.

Greetings

The greetings tab in the Dialogue window of the Construction Set allows you to modify and add the responses given by NPCs before any topics are clicked. These are very useful in quests, especially to introduce or direct the player to quest-relevant topics.

However, they should not be overused – scripting, choices, and long exposition should generally be provided in regular topics.

Likewise, you should not initiate a quest (i.e., give the first journal update) on a greeting – this makes it harder for players to keep their journals clean.

When adding greetings in Tamriel Rebuilt and Project Tamriel, there are only a few 'Greetings' tabs you will commonly use, without a very clear reason as to your deviation (for an overview of all the Greetings tabs, see the Writing and Dialogue Guidelines).

Greeting 1: dialogue that is essential or prompted by a ForceGreeting should go here. ForceGreetings are 'once only' events, so if the intended greeting gets hijacked by a Diseased, Unclothed or Vampire greeting, it may well break your quest. Therefore ForceGreetings, or any others which should not be filtered out in favour of the above, should go high up in the Greetings chart.

Greeting 5: All quest related greetings that aren't ForceGreetings should be placed here.

Greeting 7: For use in NPC claims. Greetings for unique NPCs and and for NPC class-based chatter.

Greeting 9: Also for use in NPC claims. Greetings based on an NPC's location.

Scripting

Most quests will involve some amount of scripting, allowing you to make the Morrowind game world more dynamic. Thankfully, mwscript is very simple language that non-programmers can easily pick up. See the Scripting sub-page.

Quest scripting will also make heavy use of the Results box of the Dialogue window for simpler things, like providing choices, setting quest stages, moving items between NPCs and the player, etc.

Items

If your quests rely on using unique items created by you, and detecting them by ID, it is a good idea to give these items an enchantment right off the bat. This is because enchanting an item in-game will change its ID, possibly breaking your script.

Cleaning Your Files

On how to clean files, see the TESAME tutorial.

Just like Interiors, you want to clean out anything you didn't change. Here are the most common ways a quest mod can be dirty.

NPCs

Adding dialogue to an existing NPC does not constitute changing the NPC. If you use a pre-existing NPC to create a new one or access the dialogue window, you may end up marking them as "changed" even if you didn't change anything.

Dialogue

If you add that dialogue to a pre-existing topic, such as greeting 5, it will mark the dialogue entries above and below the added ones as changed even if you haven't changed them. Clean them out.

A harder case: When you duplicate a dialogue line (by right-clicking on it in the dialogue window and selecting "Copy"), you get two dialogue lines saying the same thing. It is important to know that the upper of these lines is the new one you just created, while the lower one is the old line. So you should edit the upper line, and later clean out the lower line (unless you duplicated a line from your own mod, in which case it's all fine and you don't need to clean). If you do it the other way round, you end up overwriting someone else's dialogue! If you are proficient with command line tools, a way to *find* such problems is using tes3cmd:

tes3cmd common "Data Files\Morrowind.esm" "Data Files\[your mod].esp"
tes3cmd common "Data Files\Bloodmoon.esm" "Data Files\[your mod].esp"
tes3cmd common "Data Files\Tribunal.esm" "Data Files\[your mod].esp"
tes3cmd common "Data Files\TR_Data.esm" "Data Files\[your mod].esp"

and checking for all INFO: entries in the output. (DIAL: and LTEX: entries are OK and don't count as dirty.) Then tes3cmd delete can be used to get rid of them, but remember to put your dialogue lines back into your mod.

Cells

The Construction Set likes to create dirty cell references (refs) even when you do not change cells – this is normal, usually about three or four of them, seven or more when Tamriel Rebuilt files are loaded – and they must be cleaned. Sometimes the only cell-change you make is adding one quest NPC along the road. In such a case it can be difficult to tell which cell you changed, because exterior cells often don't have a name listed in TESAME. What you need to do is double-click on the cell reference in TESAME. The program will display details as to what was changed in that cell. If you don't see something you put in there, it's a dirty cell and should be cleaned out.