Editing Arcane University:Dialogue Systems for Writers

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 63: Line 63:
 
Greetings can be in a fixed or in a random order. In non-quest dialogue, they are typically in a fixed order, and are written with this in mind. Note how the more important, introductory Greeting comes first, followed by ones that are just flavor text. Greetings of this kind will be implemented with a reset timer so that each one will only run once until some amount of in-game time has passed, at which point it can run again. Although the NPC may seem like an amnesiac for bidding the Player welcome a second time, this is common practice and helps keep custom dialogue active in the game. When all Greetings are on a timer, the NPC will fall back to generic dialogue (see below).
 
Greetings can be in a fixed or in a random order. In non-quest dialogue, they are typically in a fixed order, and are written with this in mind. Note how the more important, introductory Greeting comes first, followed by ones that are just flavor text. Greetings of this kind will be implemented with a reset timer so that each one will only run once until some amount of in-game time has passed, at which point it can run again. Although the NPC may seem like an amnesiac for bidding the Player welcome a second time, this is common practice and helps keep custom dialogue active in the game. When all Greetings are on a timer, the NPC will fall back to generic dialogue (see below).
  
:::: '''Implementer's note''': The value of this reset timer is inconsistent in vanilla, as you'll find reset times including 0.5, 2 or even 8 hours.
+
:::: '''Implementer's note''': A value for the reset timer which is consistent with vanilla seems to be 8 hours.
  
 
Instead of a reset timer, a line can be set to run only once in the entire playthrough. This is sometimes used for an initial Greeting if the NPC formally introduces themselves, but it is likely to go over the Player's head, as it passes quickly and will never be heard again.
 
Instead of a reset timer, a line can be set to run only once in the entire playthrough. This is sometimes used for an initial Greeting if the NPC formally introduces themselves, but it is likely to go over the Player's head, as it passes quickly and will never be heard again.
Line 73: Line 73:
 
: 4. My back's acting up...
 
: 4. My back's acting up...
  
Although a Greeting can technically consist of multiple lines, this is arguably not desired, because the Player can select an option in the dialogue menu r exit out before the second line has had a chance to come up. It is also never seen in vanilla.
+
Although a Greeting can technically consist of multiple lines, this is not desired, because the Player can select an option in the dialogue menu before the second line has had a chance to come up. Consider this example, where the second Greeting is instead a followup line of the first:
 +
 
 +
:: <u>Greetings</u>
 +
: 1. Welcome, traveler. What brings you to these mines?
 +
:: 1.1. If you mine anything of value, it's yours to keep.
 +
: 2. My back's acting up...
 +
 
 +
At the start of 1., the dialogue menu is available. If the Player does nothing for a while, 1. will finish and 1.1. will be spoken. If the Player is quick enough to select a dialogue option while 1. is still running, however, 1.1. will not run and is put on the same reset timer as 1., causing the Player to miss out on this line. Compounding this is that multi-line Greetings do not appear in Vanilla and the Player is therefore not trained to wait for them. For these reasons, Greetings with multiple lines are not idiomatic to Skyrim and shouldn't be used.
  
 
One common pitfall is to write the dialogue options as though they are replies to a Greeting which the NPC is assumed to speak first. Consider this broken example:
 
One common pitfall is to write the dialogue options as though they are replies to a Greeting which the NPC is assumed to speak first. Consider this broken example:
Line 84: Line 91:
 
::: 1.2.1. ''(etc)''
 
::: 1.2.1. ''(etc)''
  
As mentioned before, Top-Level Branches have to start with a dialogue option chosen by the player, so starting with 1. seems to be an error. We could instead treat it as a Greeting with a reset timer, and 1.1. and 1.2. as top-level branches. After 1. has been spoken once, however, the next conversation will open with a different Greeting, and then 1.1. and 2.2. will be non-sequiturs. Imagine the flow of conversation if a generic Greeting is active:
+
As mentioned before, 1. will typically be a Greeting with a reset timer. After it has been spoken once, the next conversation will open with a different Greeting, and 1.1. and 2.2. will be non sequiturs. Imagine the flow of conversation if a generic Greeting is active:
  
: NPC: "Hello."
+
: "Hello." "Nothing, but I was wondering how long you've been working here."
: Player: "Nothing, but I was wondering how long you've been working here."
+
  
 
Moreover, when the end of a Branch is reached, the top-level dialogue menu returns, leading to more non sequiturs:
 
Moreover, when the end of a Branch is reached, the top-level dialogue menu returns, leading to more non sequiturs:
  
: NPC: "Back then, this place was a frontier. Well, in some ways, it still is."
+
: "Back then, this place was a frontier. Well, in some ways, it still is." "Just taking a look. Do you have any family here?"
: Player: "Just taking a look. Do you have any family here?"
+
  
 
Although it ''is'' possible to force 1. to always open the conversation, this will feel extremely repetitive, as it will seem as though the exact same conversation is repeating itself over and over. The proper solution here is to split 1. into one or more greetings, and rewrite 1.1. and 1.2. to be more general, so that they no longer require a specific line to precede them. The result of this would be the correct examples further above.
 
Although it ''is'' possible to force 1. to always open the conversation, this will feel extremely repetitive, as it will seem as though the exact same conversation is repeating itself over and over. The proper solution here is to split 1. into one or more greetings, and rewrite 1.1. and 1.2. to be more general, so that they no longer require a specific line to precede them. The result of this would be the correct examples further above.
  
As a final note, there are NPCs whose entire unique dialogue consists of a short stack of Greetings. This means they will simply say a line when spoken to, without a dialogue menu opening up (although a dialogue menu can still appear if there is a quest active that gives them dialogue). Greetings-only NPCs can be nonetheless memorable, as attested to by [https://en.uesp.net/wiki/Skyrim:Nazeem Nazeem], who became one of the most infamous NPCs in Skyrim with just this:
+
As a final note, there are NPCs whose entire unique dialogue consists of a short stack of Greetings. This means they will simply say a line when spoken to, without a dialogue menu opening up (although a dialogue menu can still appear if there is quest-related dialogue). It is good to have a healthy number of such NPCs in a settlement, as they can add a lot of flavor without bogging the player down in endless dialogue trees. For proof of the impact that such minimalist dialogue can have, look no further than [https://en.uesp.net/wiki/Skyrim:Nazeem Nazeem], who became one of the most infamous NPCs in Skyrim with just this:
  
 
:: <u>Greetings</u>
 
:: <u>Greetings</u>
Line 112: Line 117:
 
: 3. Don't be a stranger, stranger.
 
: 3. Don't be a stranger, stranger.
  
Like with Greetings, a Farewell can technically have multiple lines, but this is again not seen in vanilla and arguably a bad idea to write.
+
Like with Greetings, a Farewell can technically have multiple lines, but this is again not idiomatic to Skyrim and is bad practice. As soon as the first line begins, the dialogue menu closes, and the Player is free to run away or re-enter dialogue with the NPC before the second line has had a change to begin.
  
 
NPCs like Nazeem who have only Greetings and no Dialogue Branches also will not say any Farewells (except in the rare and temporary case where there happens to be quest-related dialogue), so it doesn't make much sense to write custom Farewells for them.
 
NPCs like Nazeem who have only Greetings and no Dialogue Branches also will not say any Farewells (except in the rare and temporary case where there happens to be quest-related dialogue), so it doesn't make much sense to write custom Farewells for them.
Line 129: Line 134:
 
1.2.1.2. will return the Player to the top-level dialogue menu, whereas 1.2.2.1. will close the dialogue menu altogether. Note that the player can still re-initiate dialogue right after, so these kinds of lines shouldn't be so hostile that it is no longer believable to have a normal conversation afterwards. It is possible to have the NPC refuse to speak to the Player and say some rude one-liners instead, but this is an extreme measure that is typically reserved for bad endings of quests.
 
1.2.1.2. will return the Player to the top-level dialogue menu, whereas 1.2.2.1. will close the dialogue menu altogether. Note that the player can still re-initiate dialogue right after, so these kinds of lines shouldn't be so hostile that it is no longer believable to have a normal conversation afterwards. It is possible to have the NPC refuse to speak to the Player and say some rude one-liners instead, but this is an extreme measure that is typically reserved for bad endings of quests.
  
Dialogue lines that exit dialogue do not have the same caveats as with Farewells regarding multiple lines; the dialogue menu will only close when the last line has been said.
+
Dialogue lines that exit dialogue have the same caveats as with Farewells regarding multiple lines, so 1.2.2.1. was deliberately written to be just one line. Situations like this should be avoided:
 +
 
 +
::: 1.2.2. '''It's been a while. I bet you're just about ready to hit the retirement home.
 +
:::: 1.2.2.1. What did you just say about me, you little s'wit?
 +
:::: 1.2.2.2. I'll have you know I graduated top of my class in the Aubere Academy, and I've been involved in numerous secret raids on Totambu.
 +
:::: 1.2.2.3. ''(etc)'' '''(exit dialogue)'''
  
 
It should also be noted that dialogue cannot end on the dialogue option itself, so this is impossible:
 
It should also be noted that dialogue cannot end on the dialogue option itself, so this is impossible:
Line 291: Line 301:
 
1.2.1. is an appropriate response to the Player declining the quest. However, the Player can also "decline" by just canceling out of dialogue, at which point a Farewell will be spoken, which might be completely inappropriate.
 
1.2.1. is an appropriate response to the Player declining the quest. However, the Player can also "decline" by just canceling out of dialogue, at which point a Farewell will be spoken, which might be completely inappropriate.
  
: NPC: "Please, adventurer, I beg of you, save my children! They must be terrified in that cave!"
+
: "Please, adventurer, I beg of you, save my children! They must be terrified in that cave!" (Player exits out of dialogue) "Stop by again any time, friend!"
: (Player exits out of dialogue)
+
: NPC: "Stop by again any time, friend!"
+
  
 
Thankfully, whenever there are dialogue choices, one of the options can be designated as '''Walk Away''' and will be spoken instead of a Farewell if the Player exits out of dialogue at that point. Usually, the implementer's own executive acumen should suffice to identify and apply such decisions, so that the writer doesn't have to prescribe Walk Away dialogue in every instance. Here, it goes without saying that 1.2.1. should be marked as Walk Away.
 
Thankfully, whenever there are dialogue choices, one of the options can be designated as '''Walk Away''' and will be spoken instead of a Farewell if the Player exits out of dialogue at that point. Usually, the implementer's own executive acumen should suffice to identify and apply such decisions, so that the writer doesn't have to prescribe Walk Away dialogue in every instance. Here, it goes without saying that 1.2.1. should be marked as Walk Away.
Line 317: Line 325:
 
:::: '''Implementer's note''': (walk away) is just an arbitrary label, and must not be taken to mean an explicit (walk away) dialogue option that can be selected. Such a line should be implemented by linking to it as a topic, selecting it as the Walk Away line, and checking the "Walk Away invisible in menu" box.
 
:::: '''Implementer's note''': (walk away) is just an arbitrary label, and must not be taken to mean an explicit (walk away) dialogue option that can be selected. Such a line should be implemented by linking to it as a topic, selecting it as the Walk Away line, and checking the "Walk Away invisible in menu" box.
  
One hidden danger caused by the Player being able to cancel out of dialogue is that it can lead to exploits. Ordinarily, if the Player quits out of important quest dialogue without a Walk Away line being specified, they must simply talk to the NPC again and run through the dialogue from the beginning again, which is immersion-breaking but functional (and it's their own fault for exiting dialogue anyway).
+
One hidden danger with the Walk Away system is that it can lead to exploits. Ordinarily, if the Player quits out of important quest dialogue without a Walk Away line being specified, they must simply talk to the NPC again and run through the dialogue from the beginning again, which is immersion-breaking but functional (and it's their own fault for exiting dialogue anyway).
  
 
However, an exploit can occur if the Player receives a reward without the Quest advancing at the same time. Consider this example, where the Player turns in a quest, and receives the next quest in the same conversation:
 
However, an exploit can occur if the Player receives a reward without the Quest advancing at the same time. Consider this example, where the Player turns in a quest, and receives the next quest in the same conversation:
Line 327: Line 335:
 
:::: 1.1.1.2. Vanquishing this fell beast is the next step in your trials. '''(advance to next stage)'''
 
:::: 1.1.1.2. Vanquishing this fell beast is the next step in your trials. '''(advance to next stage)'''
  
If the player cancels out at 1.1.1., then they may be able to re-enter dialogue and select 1. again, and receive another 1000 gold, over and over.
+
If the player cancels out at 1.1.1., then they may be able to re-enter dialogue and select 1. again, and receive another 1000 gold, over and over. One way to mitigate this would be to mark 1.1.1.1. as Walk Away dialogue, forcing the questline to continue no matter what, but this line is phrased as a direct reply to 1.1.1., and would be a non sequitur if spoken as a Walk Away. Thus, it might be a good idea to provide a custom written Walk Away line.
  
There are several possible remedies. One way to mitigate this would be to mark 1.1.1.1. as Walk Away dialogue, forcing the questline to continue no matter what, but this line is phrased as a direct reply to 1.1.1., and would be a non sequitur if spoken as a Walk Away. Thus, it might be a good idea to provide a custom written Walk Away line. In this particular example, the most sensible solution is probably to end the dialogue branch at 1.1., change 1.1.1. to a Top-Level Branch, and have it be unlocked by 1.1. That said, custom Walk Away lines can sometimes be convenient solutions and implementers should feel encouraged to identify and suggest such lines where appropriate, as it is easy to forget that this feature exists in the first place.
+
: 1. '''I have slain the Gryphon of Evermore.'''
 +
:: 1.1. Amazing, my friend! Here is your reward. That is, the riches. The fame is not ours to bestow. '''(receive 1000 gold)'''
 +
::: 1.1.1. '''Do you have any other marks in need of slaying?'''
 +
:::: 1.1.1.1. As a matter of fact, yes! The King has put out a bounty for the Werehare of Dunlain.
 +
:::: 1.1.1.2. Vanquishing this fell beast is the next step in your trials. '''(advance to next stage)'''
 +
::: 1.1.2. '''''(walk away)'''''
 +
:::: 1.1.2.1. Your next trial is to vanquish the Werehare of Dunlain, a truly fell beast indeed. '''(advance to next stage)'''
 +
 
 +
Implementers should be encouraged to identify and suggest such lines where appropriate, as it is easy to forget that this feature exists in the first place.
  
 
= Services Dialogue =
 
= Services Dialogue =
Line 359: Line 375:
 
:: 2.2. Somewhere along the way, I started experimenting with axes, and haven't looked back ever since.
 
:: 2.2. Somewhere along the way, I started experimenting with axes, and haven't looked back ever since.
  
The reason for this is because the barter dialogue is no longer a Top-Level Branch. On the other hand, if it is kept as Top-Level, then it is actually quite easy to vary the dialogue option:
+
The reason this example is so bad is because the barter dialogue is no longer a Top-Level Branch. On the other hand, if it is kept as Top-Level, then it is actually quite easy to vary the dialogue option:
  
 
: 1. '''Can I buy some of your axes?'''
 
: 1. '''Can I buy some of your axes?'''
Line 367: Line 383:
 
:: 2.2. Somewhere along the way, I started experimenting with axes, and haven't looked back ever since.
 
:: 2.2. Somewhere along the way, I started experimenting with axes, and haven't looked back ever since.
  
However, take caution with this, as the default line ("What have you got for sale?") is an established gameplay convention in vanilla, and players will look for this line if they want to sell something. This is equally true for innkeeper rent room dialogue ("I'd like to rent a room. (<Global=RoomCost> gold)"). For trainer dialogue, there are some minor variations in phrasing for the different skills, but not much ("I'd like training in Alchemy", "I'd like to train in One-Handed weapons", "Can you teach me about Conjuration?" and so on). See [https://en.uesp.net/wiki/Skyrim:Generic_Dialogue#Requesting_training UESP for the complete list].
+
However, you ''must not'' do this, because the default line ("What have you got for sale?") is an established gameplay convention, analogous to the barter button in Oblivion, but in the form of a dialogue line. Changing this line obfuscates the fact that a barter menu will appear, and creates an inconsistency with regard to Skyrim. There is a reason this line was never varied in Vanilla: the player has been trained to look for this line, and as long as it is retained, they will know at a glance whether they are able to barter with an NPC or not. This is equally true for innkeeper rent room dialogue ("I'd like to rent a room. (<Global=RoomCost> gold)"). For trainer dialogue, there are some minor variations in phrasing for the different skills, but not much ("I'd like training in Alchemy", "I'd like to train in One-Handed weapons", "Can you teach me about Conjuration?" and so on). See [https://en.uesp.net/wiki/Skyrim:Generic_Dialogue#Requesting_training UESP for the complete list].
  
:::: '''Implementer's note''': Custom responses for Services Dialogue should be implemented as TopicInfos in the same stack as the Generic Dialogue, but near the top, so that it takes precedence. The displayed dialogue option can be controlled with the Prompt field. Be sure to duplicate any relevant conditions (GetOffersServicesNow for barter, faction membership for trainers, etc) and add whichever conditions are needed to narrow it down to your NPC and the appropriate circumstances.
+
:::: '''Implementer's note''': Custom responses for Services Dialogue should be implemented as TopicInfos in the same stack as the Generic Dialogue, but near the top, so that it takes precedence. The displayed dialogue option can be controlled with the Prompt field, which should only be used for trainer dialogue. Be sure to duplicate any relevant conditions (GetOffersServicesNow for barter, faction membership for trainers, etc) and add whichever conditions are needed to narrow it down to your NPC and the appropriate circumstances.
  
 
Don't feel pressured to write unique Services dialogue for every single NPC that can have it. That would make the actual generic dialogue rather pointless. If no custom lines are written, then it should suffice to mention in the NPC document which services the NPC will offer and when, without having to add the dialogue line to the tree explicitly; the implementer will then add the NPC to the appropriate factions, which will enable the appropriate generic dialogue.
 
Don't feel pressured to write unique Services dialogue for every single NPC that can have it. That would make the actual generic dialogue rather pointless. If no custom lines are written, then it should suffice to mention in the NPC document which services the NPC will offer and when, without having to add the dialogue line to the tree explicitly; the implementer will then add the NPC to the appropriate factions, which will enable the appropriate generic dialogue.
Line 530: Line 546:
 
== Intimidate ==
 
== Intimidate ==
  
Intimidate has success and failure results just like Persuade checks, but instead of being based solely on the Player's Speech, success is primarily based on the NPC's AI [https://ck.uesp.net/wiki/AI_Data_Tab#Confidence Confidence Level], and a host of other factors such as the NPC's and the Player's level, and Speech (see "Mod Player Intimidation" on the [https://ck.uesp.net/wiki/Perk_Entry_Point Perk Entry Point] CK wiki article for the full formula). As such, it is not easy to specify a difficulty for Intimidate checks; at best, specifying [Hard] will lead the implementer to set the NPC's confidence level to Brave, which also makes it so that they will rarely run away from battles, whereas specifying [Very easy] will lead them to being made Cowardly. Keep this in mind and perhaps mention the presence and required difficulty of an Intimidate check on the NPC's general document. Also do not have multiple Intimidate checks with different difficulty levels on the same NPC. It could theoretically be done by putting a perk with the Mod Player Intimidation perk entry point on and off the player, but it's probably more hassle than it's worth, and doesn't work if the intimidation checks are offered simultaneously in the dialogue.
+
Intimidate has success and failure results just like Persuade checks, but instead of being based solely on the Player's Speech, success is primarily based on the NPC's AI [https://ck.uesp.net/wiki/AI_Data_Tab#Confidence Confidence Level], and a host of other factors such as - reportedly - the NPC's and the Player's level, and perhaps also Speech (the actual formula has never been documented). As such, it is not easy to specify a difficulty for Intimidate checks; at best, specifying [Hard] will lead the implementer to set the NPC's confidence level to Brave so that they will rarely run away from battles, whereas specifying [Very easy] will lead them to being made Cowardly. Keep this in mind and perhaps mention the presence and required difficulty of an Intimidate check on the NPC's general document. Also do not have multiple Intimidate checks with different difficulty levels on the same NPC.
  
 
: 1. As you can see, the farm is doing quite well.
 
: 1. As you can see, the farm is doing quite well.
:: 1.1. '''Don't lie to me, or I'll bury you inside it. (Intimidate)''' ''[Easy]''
+
:: 1.1. '''Don't lie to me, or I'll bury you inside it. (Persuade)''' ''[Easy]''
 
::: 1.1.1. ''[success]'' O-oh! I'm so sorry, I didn't mean to lie! I was just embarrassed! Please have mercy!
 
::: 1.1.1. ''[success]'' O-oh! I'm so sorry, I didn't mean to lie! I was just embarrassed! Please have mercy!
 
::: 1.1.2. You're right, my farm isn't doing well - it was cursed by a hagraven and I'm on the brink of ruin! ''[To QUEST BRANCH]''
 
::: 1.1.2. You're right, my farm isn't doing well - it was cursed by a hagraven and I'm on the brink of ruin! ''[To QUEST BRANCH]''
Line 579: Line 595:
  
 
In Beyond Skyrim, Illusion will also appear as a speech check, but it is used as a fourth main check type alongside Persuade, Intimidate and Bribe, will give Illusion experience on success, and has failure lines.
 
In Beyond Skyrim, Illusion will also appear as a speech check, but it is used as a fourth main check type alongside Persuade, Intimidate and Bribe, will give Illusion experience on success, and has failure lines.
 
= Rumors =
 
 
Rumors are an extra aide for the player to find out about quests in the area to do. In gameplay terms, they add a dialogue option to certain NPCs (typically innkeepers) which can be repeatedly clicked to give pointers to several quests, or flavor text, in a random order. In technical terms, they allow topics from different quests to appear under the same dialogue option as if their infos were pooled under one topic. This is what the special dialogue subtype "Rumor" does.
 
 
As with any other dialogue, which NPC displays the rumor dialogue option depends on the conditions of the specific rumor dialogue lines. In theory, one could use keywords and/or factions to give all NPCs of a certain city access to a certain stack of rumors, as in previous Elder Scrolls games. However, Skyrim has moved away from this generic approach to dialogue, and instead the rumor lines appear to be directly conditioned on whichever NPC is the innkeeper in a given settlement (there's even a loadscreen explaining this to the player). This makes it so that rumors can be written in the voice of that specific NPC. In cases where one NPC can replace another as innkeeper, vanilla sometimes provides variants of each applicable rumor for both NPCs. Some rumors pertaining to major questlines or daedric quests can be heard province-wide and these are generically available to all innkeepers.
 
 
A rumor will consist of a stock dialogue option which doesn't need to be provided by the writer (it defaults to "Heard any rumors lately?") and a line spoken by the NPC. This can technically be several lines but vanilla sticks to just one per rumor, giving them a rapid-fire quality, so it would be best to follow this pattern. If the rumor is about a quest, a misc. objective may be added which points to the questgiver. Clicking the rumor dialogue could be considered as the player opting in to receiving these kinds of objectives in the journal. Therefore, the "Heard any rumors lately?" should probably be kept as-is as the player has been trained to look out for this text.
 
 
Example from a hypothetical innkeeper NPC's dialogue document:
 
 
: 4. '''<generic rumor topic>'''<br>
 
:: 4.1 People are saying Grugnur Sneaky-Fingers has been up to no good again... Color me surprised.<br>
 
:: 4.2 Did you hear about Julie Giroux? Great for her that she's getting married, but why Riften?<br>
 
:: 4.3 The guards spotted a pair of wormmouths between the hills near here. Be careful.
 
 
There may, however, be exceptions. Hulda from the Bannered Mare in Whiterun has a rumor about the Companions recruiting for new members; this rumor uniquely has the dialogue option text "Give me the latest gossip." What will happen in-game is that the text will still say "Heard any rumors lately?" if any of the other rumors were randomly selected to be said next, but that same option will suddenly read "Give me the latest gossip" if the companions rumor is next. This seems like buggy behavior and therefore the custom line should be treated as an error. The line is located in WhiterunInnkeeperRumorsBranchTopic in DialogueWhiterun.
 
 
:::: '''Implementer's note''': When a rumor topic has no topic text (and they typically don't), the in-game text is pulled from the sTopicSubtypeTextPlayerDialogueRumors game setting, which by default is "Heard any rumors lately?"
 
 
The big advantage of the Rumor subtype is that rumors can be implemented in different quests without causing a proliferation of dialogue options, and therefore it is of no inconvenience to the implementer if these rumors are provided by the writer scattered around different documents. While the above example may come from the NPC's standard dialogue document, as those rumors are just flavor text for the region, rumors that lead to specific quests can be provided in the document for that quest, and implemented within the scope of that quest.
 
 
:::: '''Implementer's note''': For quests that have a full journal entry, the miscellaneous objective that comes from a rumor is instead implemented in a small, separate "rumor" or "pointer" quest which also holds the rumor line, otherwise the full journal entry would be added before even talking to the questgiver.
 

Please note that all contributions to Beyond Skyrim are considered to be released under the Creative Commons Attribution-ShareAlike (see Beyond Skyrim Wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)

Template used on this page: