User:Thingy Person

Welcome to the Arcane Mystic assignment for quest and dialogue implementation, where you will implement the small settlement of Marlinsvik, situated on Skyrim's northwestern coast. Although the scope of the settlement has been kept small, it is still a beefy exercise, and by the time you're done, you will have familiarized yourself with a sizeable amount of Creation Kit elements that will be useful for a project and for your own mods.

The writing document folder for Marlinsvik can be found here:

And you can load this esp as your active file and build off of it. It contains level design for the village, although the houses are of course still unpopulated:

This document, originating from the Beyond Skyrim: Cyrodiil project, lists many of the required steps, although some of its contents go beyond the scope of this exercise. This AU lecture gives a general overview of the work all of this entails. For the most part, though, you can just rely on the instructions below.

As before, use a prefix of three or four letters (such as "AUM", for Arcane University Mystic) that you will use in all EditorIDs of objects that you create. Make sure to also set this prefix in the "Papyrus" tab of the Creation Kit Preferences window. This will automatically add "<prefix>_" to the name of any fragment script that it creates. For manually created scripts, make sure to include your prefix manually when you choose the name.

The exercise can be divided into four parts, taking you across all of the essential steps in implementing a settlement. Feel free to ask for feedback partway through if you are running into issues or are unsure that you're doing things correctly.

• Basic setup of the NPCs and any data needed to make the settlement function
• Dialogue and scenes
• AI packages
• Quests

Setup

• Creation of the NPC records
  • It is best to start with creating the Actor base records of the five NPCs (including the dog). Set them as "Unique", write their full name in "Name" and, if they have a surname, write only their first name in "Short name". EditorID should be of the format "<prefix>FirstnameLastname".
  • Thankfully, you do not need to waste time recreating their faces, because the writer has supplied .npc files for them in the "Facedata" folder that you can import. Set the actor to any of the playable races so that the "Character Gen Parts" tab becomes visible. Under this tab, click the "Import" button and select the .npc file. This will take care of setting the correct race, sex, weight and face data.
    • Wiske, being a child and thus not a playable race, does not have an .npc file, so you will have to improvise based on the written description.
    • Gaubelin is described as an Elder, which is technically a separate race designed to look older than the playable races. The .npc file is for a Breton instead; after importing, you can try setting his race to an Elder, which preserves most elements, but arguably looks worse. You can decide how to go about this. Note that the Elder race does not distinguish between Nords and Bretons and doesn't confer racial bonuses.
  • You will, however, need to configure the NPC's stats and inventory. Unique settlement NPCs tend to have static level, so don't use the "PC Level Mult" flag. A level between 5 and 10 seems appropriate for ordinary people; compare with NPCs from a similarly sized settlement like Shor's Stone for example. Combat-focused NPCs can be a bit more. You can use the "Auto calc stats" flag which will compute individual skills based on the level and their class. Set this class to something suitable rather than the default "EncDremoraMelee".
  • For their inventory, pick an Outfit that seems suitable and ideally fits the written description. Sometimes, you may have to create a new Outfit, but this shouldn't be necessary here. It is generally good to add a "LootCitizenPockets..." leveled list to the inventory so that they have some randomized objects on them.
  • For AI Data, make sure they at least help allies (i.e. close family) and possibly friends and allies.
  • For Gaubelin, don't forget to give him spells. You have some leeway to be creative here.
  • Once all NPCs have been created, set Relationships between them. Each pairing of NPCs that know each other should get a relationship if they are at least friends, or rivals.
    • Pick an association type that best fits their relationship. For example, Jerome is not Wiske's father, but stands in for one, so arguably you could choose ParentChild. Family and lovers should get the "Ally" rank, others "Friend".
    • The EditorID format is <prefix><Parentname><Childname>, where Parent is the "senior" NPC and Child the "junior" NPC. For association types that are essentially equal, the ordering is not important.
• Creation of Locations records
  • A Location is an abstract piece of data that holds information which could potentially be used in radiant quests. Create a "<prefix>MarlinsvikLocation" location and give it suitable keywords describing what kind of location it is (you can look at the Shor's Stone location for reference). Make its parent the Haafingar location.
  • Create Locations for each of the houses with the format "<prefix>Marlinsvik<Housename>". Since Gaubelin's shack has no interior, it doesn't need a Location. Set the Marlinsvik location from the previous step as the parent.
• Creation of Faction records
  • Create a "<prefix>TownMarlinsvikFaction" faction and also a faction for each house with the format "<prefix>Marlinsvik<Housename>Faction". Again, Gaubelin doesn't need one.
  • Apply the "Town" faction to each NPC and also apply the faction of the house that they reside in.
  • Apply the relevant crime faction (i.e. CrimeFactionHaafingar) to every NPC and select it in the "Assigned crime faction" dropdown.
  • Certain NPCs will need even more factions to enable all of their required functions, but we will do those in the next step.
• Creation of keys and lock lists
  • Jerome and Caechabhu's houses will need to be locked at night or when they are out and about. Create a Key for each house with the format "<prefix>Marlinsvik<Housename>Key". You can duplicate a vanilla object so you don't have to manually specify a model and pickup sounds. Add an instance of the key to the inventory of the NPCs that live there... except for the dog.
  • Next, create a FormList for each house with the format "<prefix>Marlinsvik<Housename>LockList". Fill this list with the Actor base records of the relevant NPCs.
• Apply it all to the cells
  • Let's start with the exterior. Every cell that contains even a small part of the settlement should be marked as such. In the cell window, right click and "Edit" the cell. Set the Location to the <prefix>MarlinsvikLocation that you created. Also change the editorID to a convention like "<prefix>Marlinsvik01" if it isn't named that already. You can rename a cell by single clicking the name in the cell window.
  • Load up a house interior. Set the Location to that house's location. Then in the Interior Data tab, set "Owner Faction" to the house faction you created, and "Lock List" to the respective lock list.
  • Edit the door. Give it a Lock that is tied to the key you created; the lock level can be Novice for commoners such as these. Also set the owner faction to the house faction. It is crucial for the inside reference of the door to be owned in this way for trespassing to work properly.
  • Place the NPCs near the beds where they sleep. Set the faction of the bed to that NPC so that nobody else will sleep there. Edit the NPC's ref and name it "<prefix><NPCname>REF" (this makes it show up in-game with the "help" console command, making it easy to teleport to the NPC if needed). Then, under the "Persistence location" tab, set the dropdown to the <prefix>MarlinsvikLocation. This controls when the NPC is persistent, i.e. having its pathing calculated by the game even if not in the currently loaded area. Choosing this as the persist location means the NPC is processed if any part of Marlinsvik's exterior or interior is currently loaded. In your .esp, all references are persistent at all times anyway, but when an .esp gets merged into an .esm file like in a project, that is no longer a case. If NPCs for some reason aren't coming out of their houses even though they should, this is often why. Also, the "Unique actor" fill method in quest aliases has been found to fail sometimes if the NPC ref doesn't have a persist location.
  • In the exterior, set the ownership of any somewhat valuable item to the <prefix>TownMarlinsvikFaction so that it can't be taken without it being considered stealing. You can use the Batch Assignment tool to save some time.
    • For the interiors, the cell's owning faction takes care of this automatically. Since Gaubelin's shack has no interior, you will have to assign his posessions to him manually.

Dialogue and scenes

• You will have a single start game enabled quest called <prefix>DialogueMarlinsvik that holds all the regular, non-quest related dialogue for this settlement.
  • Greetings and Farewells go under the Misc tab. Create a topic of subtype "Hello"; this will contain all the greetings for 'all' the NPCs in a single stack of Infos. Same with the Farewells, which go in the subtybe "Goodbye".
    • In Skyrim, unique NPC greetings usually just get a reset timer, typically of 0.5 hours. This means they are heard in sequence until they have all had a turn and the NPC drops down to generic lines ("Yes?", "Need something?" and so on) until half an in-game hour has passed and the lines reset. That said, writers often do not write greetings and farewells with a specific order in mind, so giving them the Random flag is an option. If you do this, be sure to set Random End on the NPC's last line in the stack, or generic lines will be interspersed with the unqiue ones.
    • Some greetings depend on the completion of quests that you haven't implemented yet. It's up to you how to go about this; for example, you could just make a note of which lines you need to go back to later on to add conditions. In a project, sometimes such a quest will not be available for implementation until much later, and there will have to be some organization in place to keep track of these dependencies.
    • The reason these quest-dependent greetings aren't contained in the quests themselves is that we want to be able to Stop() those quests after they are completed, but that will make all the dialogue inside of them unavailable, whereas these greetings are supposed to be heard after the quest.
  • Implement standard dialogue in the Player Dialogue tab (or Dialogue Views if you prefer). There is no standard EditorID naming scheme used consistently in the base game, but try to stick something sensible like "<prefix><Questname><NPCname><branchname><Topicindex>".
    • Refer to the list of Condition Functions for any non-standard implementation notes that the writer has asked for.
    • Sadly, there is no button or condition in the CK for "unlocking" dialogue branches, so this will have to be scripted. If a dialogue line locks (or unlocks) another dialogue branch, make a quest stage for it, and add a note saying e.g. "Locks PARENTS in Wiske's dialogue" as either a fragment script or a journal entry (since this quest won't show up in the journal anyway). Then have the line set that stage, and for the dialogue that gets locked (or unlocked), use the GetStageDone condition. This means it'll work even if the stages are not set in a numerically ascending order.
    • Occasionally, a writer may specify that dialogue should be locked or unlocked when it is not actually needed to script quest stages to do so. You always have the capacity to decide what the most elegant way to implement a given piece of dialogue is.
  • Gaubelin has an "Initial dialogue" section that is a little bit different. The conversation begins with him, not with a player dialogue option. This needs to be implemented as a Blocking Branch. A vanilla example of this is Idolaf Battle-Born's dialogue.
    • The "Alias=Player" text will work even without making a quest alias for the player; see Text Replacement.
    • One of Gaubelin's greetings is specified to be valid only while the initial dialogue tree has not been gone through. However, by default, the first line from the blocking branch will be used as the greeting, even if the player is just walking past without initiating dialogue, leaving the custom greeting with no opportunity to be heard. This is why you have to put the IsInDialogueWithPlayer condition on the blocking branch dialogue.
  • Caechabhu is a merchant, so refer to the Creating a Merchant tutorial. Her dialogue doc specifies a "What have you got for sale?" topic, but you do not need to add this, since the "JobMerchantFaction" takes care of it. Since Caechabhu is a fletcher, you additionally need to give her the "JobFletcherFaction" so she has the fletcher-specific dialogue lines. Also use the fletcher buy/sell list on her services faction.
    • Similarly, Gaubelin's "I'd like training in Alchemy" topic is also handled entirely by factions, but don't give him the factions just yet, since his services are a quest reward.
    • Projects will have their own generic dialogue lines and will thus have custom "Job" factions that you will need to use.
  • Caechabhu's dialogue contains a speech check; see the Dialogue Speech Checks tutorial.
    • It is definitely important to use the "SpeechAverage" global variable in the condition rather than a numeric value. This is because the global variables are manipulated by certain Speech perks that the player can learn, whereas using a numeric value means these perks have no effect.
    • For completeness, the success option should also have an OR condition "GetEquipped: TGAmuletofArticulationList", run on the player, in case they have the Amulet of Articulation equipped. Yes, manually adding this condition to every single persuade check is how Bethesda coded the effect of this amulet.
  • Remember that Start Game Enabled quests need a SEQ file to actually start, or you can just quicksave and quickload as a stopgap solution.
• Scenes are done differently (see also Bethesda Tutorial Scenes). Here, there are only three, although usually there are more.
  

  Markers for Brina Merilis and Skald the Elder's establishing scene in Dawnstar
  • The first scene is a major establisher. This is a scene that starts the game enabled and is manually choreographed. The NPCs will take up positions (determined by packages pointing to XMarkerHeadings that you need to place) and wait day and night for the player to come by and hear their dialogue, giving the first impression of the themes of the settlement. There will usually be an initial scene phase before dialogue that only finishes when the player enters a trigger volume around the markers, so that dialogue doesn't start until the player is reasonably within earshot.
    • In dialogue actions, set a headtrack target pointing to whoever the NPC is talking to. It is also often a good idea to put empty dialogue actions for the other NPCs to make them headtrack whoever is talking.
    • For Nabuco's bark, you can use a vanilla Shared Info (using the "Share response data from info" dropdown) that will give you a standard dog bark with no visible subtitle. Such infos can be found in the quest CreatureDialogueDog.
    • You should put this scene in its own quest, and stop the quest when the scene is done (the "Stop quest on end" flag on the scene can be used for this). The reason for this is that the quest aliases needed for the scene make the NPCs persistent as long as the quest is running. Although, again, all references in an esp file will be persistent at all times.
  • The other two scenes are random conversations. We will let the game engine trigger these for us whenever two NPCs get within talking range of each other. The trigger mechanism is the Story Manager (see also the Bethesda Tutorial Story Manager). Each of these scenes will be in its own quest. The steps for setting it up are in this tutorial which you may have seen before.
    • One of the EditorID naming conventions in use is something like "<prefix>DialogueMarlinsvik<NPC1><NPC2>Scene01" for the quest and "<prefix>DialogueMarlinsvik<NPC1><NPC2>01Scene" for the scene. This slight variation is needed because no two objects can have the same EditorID.
    • In the Actor Dialogue story manager event node, there is a whole network of branch nodes that group scene quests by hold and then by settlement. If you were to follow this scheme, you would make a new node for Marlinsvik under HaafingarHoldScenes. However, we recommend that you keep your modded content separate from the base game, so make a top-level node for your assignment (and mark it as "Shares event" to play nice). A project will typically have a top-level node like this, and maintain their own structure down from that node.
    • The second random conversation is a 3x3 scene. This is an in-house invention where each dialogue phase will feature one random line out of three possibilities. Implementing this is easy: in a given dialogue action, have the dialogue topic contain three TopicInfos that are flagged "Random".

If you have done everything correctly up to this point, the major establishing scene will play out and then the NPCs will lock themselves inside their homes. You can use the "unlock" console command on the door to get inside quicker, but the NPCs will be yelling at you for trespassing, making it difficult to test the dialogue. Using the console command "toggledetection" (or "tdetect") will make them more cooperative. You won't be able to test all of the scenes until their daily schedules have been made, which is the next step.

AI Packages

Now that you have first-hand experience with the NPCs and their dialogue (although it would be good to take a cursory look at the quests too), it's time to think about their daily schedules. These are implemented in the form of AI Packages (see also this page for an explanation of all the settings in a package). Since NPCs' standard schedules aren't quest-related, these packages belong in the AI Packages Tab of the relevant NPC.

The aim is to create a feeling of hustle and bustle in the settlement and make it come alive, while properly conveying each NPC's background through what the player sees them do, and making sure that NPCs will meet each other if they have a possible scene together. You will have noticed a schedule specified in each NPC's document. These are more like guidelines or suggestions than something to be implemented literally; as the person working directly in the game engine, you will have a better intuition of what works well in-game. One in-game hour is a lot shorter than how it may seem on paper; this is especially true if an NPC needs to travel a long distance between activities. But you will also have a direct view of the environment and everything in it that you can work with, as well as quick access to all the settlements in vanilla Skyrim that you can compare with. So this section entails some genuine creative freedom.

• Try to use pre-existing, reusable packages when it is convenient to do so. These all have EditorIDs beginning with "default". They often point to the NPC's editor location as their destination; the editor location is wherever you placed the NPC's reference in the world, namely inside their house, which is what makes these packages useful.
  • It's generally a good idea to stick a "defaultSandboxHomeowner" or a similar package at the bottom. This will take care of any "sandboxes at home" sequences in between other activities.
  • Other than that, it's typical to organize the package stack so that earlier packages in the day are at the bottom, with later packages up top. You should be able to find "defaultSleep" and "defaultEat" packages that roughly fit the timespans you want. If a package has "16x4" at the end of its EditorID, that means it begins at 16 hours (in military time) and lasts for 4 in-game hours, so from 4 p.m. to 8 p.m.
  • Some default packages will have the "unlock doors" flag set, others not. If a package unlocks doors, that means the player is able to come inside and visit without trespassing. Eat and home sandbox packages tend to unlock doors whereas sleep packages don't; if a default package bucks this trend, it is often indicated as such in the EditorID. You generally want the player to be able to enter a house legally so that the level designers' work can be enjoyed by all.
• For most other types of packages, you will need to point to a custom location and therefore you will have to make custom packages. A convention for this is something like "<prefix><Settlement><NPC><Activity>10x2" where the 10x2 has the meaning explained previously. Make sure the times in the EditorID match up with how you configure the package itself, or you may be quite confused later on.
  • For the target of the package, you often want the NPC to be working in a general area rather than targeting a specific object. In such cases, you'll want to place an Xmarker and give the reference an Editor like "<prefix><Settlement><NPC><Activity>Marker" and use that in the package, rather than take some nearby object.
  • The radius around the target is measured in units. If you're having a hard time visualizing a certain radius, one trick is to temporarily put down a map marker and play with its discovery radius; this radius is also in units and will be shown in the CK.
  • A package with the template SandboxMultiLocation can be very useful as a broad solution. This way, you can have an NPC automatically rotate between several locations for a good chunk of their day, such as inside and outside of their home.
  • Be sure to disable "Allow eating" if applicable, otherwise the NPC will, in fact, be seen eating or drinking every chance they get.
• You will have to place additional AI markers to aid NPCs in their schedules. Level designers typically only concern themselves with things that are visible, leaving you to place idle markers, Xmarkers, and occasionally furniture objects without a visible model. Make sure to set the ownership of idle markers and furniture to a specific NPC or faction if you don't want them to be used by everyone.
  • For a demonstration of available idle animations, see this video. Most of these idles have corresponding idle markers that you can use. Of course, many animations are not suited for ordinary NPC activities.
  • Jerome's potato patch will need a good handful of FarmingIdleMarkers for him to randomly switch between. As implied earlier, his farming package should point to an Xmarker located in the middle of the patch.
  • Making an NPC carry wood takes a bit of setting up, but adds a very nice touch. The package will need the CarryItem template and point to two WoodPiles, usually one near the chopping block and the other one near the main wood stockpile. Then you should also put the CarryItemScript on the NPC and configure its properties to spawn firewood if the NPC gets interrupted mid-carry, and add fragment scripts to the package in the "Begin/End/Change" tab to activate this behavior. See Faendal from Riverwood as an example NPC who carries wood as part of his daily schedule.
  • For Caechabhu, you probably don't want her tanning leather all the time, so you can improvise by, for example, giving her a WallLeanMarker (an invisible furniture) to make her lean against her house. Or you can have her spend part of her day in a Patrol around the village and the nearby wilderness (chain a bunch of PatrolIdleMarkers together via "linked reference", make a package with the Patrol template, and point it to a marker in the chain), evoking the impression that she's hunting.
  • For children like Wiske, it can be difficult coming up with things for them to do, since they can't perform working activities such as farming. If multiple children are around, you can make them run around along a patrol path to simulate them playing tag. Otherwise, having a child stand around doing nothing can often do the job. Maybe place an InvisibleChairMarker to use if there is a suitably-sized rock or crate in the village.
  • Gaubelin will get some mileage out of his alchemy set, but also experiment with putting markers like the StudyIdleMarker around his shack.
  • Inside a house, placing a SweepIdleMarker or two can work well. If there is a cooking set, the NPC will use that too.
• For testing, consider using More Informative Console, which displays an NPC's current AI package.

Quests

Lastly, the assignment includes two small quests. These are no more remarkable than the Bendu Olo and Arcane Scribe quests you've already seen, but they include some twists that are useful to familiarize yourself with.

In Skyrim, EditorIDs for misc tasks have a hodgepodge of contrasting conventions, usually containing the words "Freeform" or "Favor". Here, we recommend you use "<prefix>MarlinsvikFF01" and "<prefix>MarlinsvikFF02" for the two quests.

• "Find Wiske's doll" is a so-called radiant quest, since the dungeon is randomly selected. Refer to the Bethesda Tutorial Radiant Quests for a refresher.
  • Dungeons usually have a "LocSet" keyword for the tileset it uses and a "LocType" keyword for who or what resides there. You can use the GetInCurrentLoc condition function to restrict the search to Haafingar. Ironically, there will only be one eligible location, namely Steepfall Burrow.
  • You could script this quest to start during Wiske's dialogue, or you could have it start game enabled, like these kinds of quests usually are in vanilla. That means the player can come across Skanulike in a chest before ever visiting Marlinsvik, hence the dialogue option taking this possibility into account. Vanilla is less ceremonious about this.
    • Another possibility of starting the quest in use in some Beyond Skyrim projects is with the Change Location story manager event node, distributing the load so that the quests in a locatation get started when the player travels there rather than all at game start.
  • If a line is formatted in light blue, that means it is repeated from earlier and mustn't be implemented as a separate line, or the voice actor will be prompted to record the same line twice. Sometimes you can manage it with invisible continues, but in other cases, you will have to make a Shared Info.
  • Don't know how to award a skill level in Speech? Take a peek at a vanilla example if you can remember one, or search the List of Papyrus Functions.
• Gather Flowers for Gaubelin is trickier, since you need to implement a live updating counter based on the player acquiring items, and several kinds of items need to be treated as though they are interchangeable.
  • It's always handy if there is a vanilla example so you can copy their homework. In this case, that would be Grin and Bear It. The UESP is often a very helpful encyclopedia for vanilla content; its list of ingredients will also be helpful here.
  • You can pretty much base your implementation off of the vanilla quest. The main issue is that you need to provide some central bit of code - a function to count all flowers in the player's inventory and update objectives if needed - and have it be accessible from multiple places, like the stage fragment script (for when the quest is accepted) and the player aliases (for when flowers are gained or lost). The best place to put this code is as a function in a new, manually created script that is attached to the quest, sitting next to the fragment script.
    • To run this function from somewhere else, you'll need to have the quest as an object, not of type Quest, but of type <the name of your script>. In a stage fragment, you can have the CK create such an object for you using the "kMyQuest" dropdown. You can then do: "kMyQuest.CountItems()" for example.
    • In an alias script (as well as a dialogue fragment script for example), you can do it like this: "(GetOwningQuest() as <name of your script>).CountItems()".
  • Don't forget to add an event filter to the player alias script for the four kinds of mountain flowers, or to add the global variable for your counter to the "text replacement globals" list in the Quest Data tab!
  • In both quests, run Stop() to clean up after you no longer need anything in the quest. You should also provide a fail stage if the NPC dies (there are default alias scripts for this), which fails all objectives and also stops the quest. This fail stage is less relevant in Wiske's quest, unless you want to account for the player using a child killing mod.