NWN2

A constant is an identifier which has a value that can not change at runtime.

This can certainly be directed toward many purposes, but the overwhelming majority of use of constants is to provide a human-readable name for something that needs to be stored and referenced as a number. This makes it easier to talk about, reference, and write with these structures. When such is used by scripters or developers, these numbers are typically written out all together with a clear human-readable name, and then assigning it the value that the underlying data structure understands. It is then used like a variable (e.g. writing code with SKILL_PARRY instead of 10), and is then automatically compiled as its cheaper/smaller integer form.

This is typically made necessary by features which are designed to be expanded or configured, or by cases where storage/retrieval is faster or more efficient if the data is stored and handled as numbers, and only translated to human-readable output when displaying for human consumption. Examples of things that are actually integers would be skills, feats, spells, cleric domains, visual effects, or character classes. Examples of things that are not referenced by constants would be items (not item properties or base item types-- the items themselves), areas, or waypoints.

When used by builders, it often becomes necessary to learn a constant's value, due to things like the conversation editor not accepting constants by their names. These are typically stored in include files, such as nwscript.nss (which is present in every module, and contains constants defined by OE), acr_i.nss (which contains many constants which are specific to the ACR), or dmfi_inc_const.nss (which contains many constants which are specific to dmfi tools). You can read the lines of these files to learn what to place into a script that expects one of these constants. For instance, line 148 of acr_i contains this line:

const int SKILL_DECIPHER_SCRIPT = 32;

This tells you that, if you needed to refer to decipher script in a place that only accepts a number, that number would be 32.

A quest turnin is the last part of a quest. It provides rewards for the completion of the quest and sets the quest to its finished state.

Quest Turnins in Conversations

This is the most common kind of turnin, as it is usually the most convenient. We usually expect to pay characters at the end of quests, and a quest turnin from an NPC is a very convenient way to do so.

The conversation tree will be a lot like the quest hook. You need a PC option to mention that work has been done, and a conversation line down that tree.

On the player bringing up the topic of work, you're going to have a conditional-- it will be just like the other ones checking for quest progress, but this time, we want to have nState be the one we set at the end of the challenge. We're also going to want to have a new journal entry, just like the ones we set up for the others. Our action script, which will be on the NPC's response to the character indicating that the job is done, will be the special one, because now we need to give out gold and XP.

So instead of acr_quest_update, we're going to use acr_quest_reward. This script does a few things:
-- It gives nGold to any character being rewarded
-- It gives the amount of XP specified in the journal classification to the character being rewarded
-- It takes away any quest item that was managed through the ACR
-- It logs that the quest was completed and the amount of XP earned
-- It updates the player's journal to read as nState is one point higher (so if the last challenge put nState at 2, this will make nState into 3)

Additionally you'll want that last journal entry to be called the endpoint of its journal category

This doesn't actually drive anything mechanical-- using acr_quest_reward is what tells the ACR that the quest is done, so that experience and rewards can be given out and our logs can say that it's complete. What it does is determine where in the PC's journal this item will appear once this state is achieved. Namely, it will start to appear on the "Completed" tab instead of the "Quests" tab. It's usually a friendly gesture to keep that particular thing up to date; it's much easier for a player to forget the errata of a video game than it is for a character to forget how they'll be paying for their food and shelter later, after all.

Checking for Items

It might also be necessary to check if a given character owns an item when turning in a quest. If the character was told to carry a message to someone, and then arrived without the message, we shouldn't pretend that everything is fine and reward them, right? But this is slightly more complex-- because what if the character killed someone with a message and stole it. They're not working for anyone here, so they'd probably have a hard time collecting payment. This means that we need to have a conversation line with two conditional scripts on it: one to look for the item and one to look for the quest.

acr_quest_progress should look familiar. It's the same conditional we're using above. We're adding a new script to this in similar pattern-- again, you'll want to click Add over the conditions and then type the script name into the script column and refresh. acr_cs_has_item takes two parameters, sTag, which is the item's tag, and sQuest, which is the quest that the item is for. You should leave sQuest blank if the item isn't dropped using the ACR Quest System, though, as it will only regard an item dropped by the quest system for the PC on the quest as valid if it's told to look for an item by the quest name.

Also notice that there's the "And" button to the left of the next line, once we've added a second one. We want it to be an "and" in this case, but if this quest could feasibly be completed by someone who found this item or by someone who was hired to work, then you could click that button and it would accept both.

The rest of the turnin follows as above in this case.

Quest Turnins on Triggers

TODO: Describe how to turn in a quest on a trigger.

Quest Turnins on Placeables

TODO: Describe how to turn in a quest on a placeable

Completed Quests as Prerequisites

One thing to note about the state of a quest after you've gotten this far-- that combination of sQuest and nState doesn't go away. Once this quest is completed, you can reference that nState anywhere you need to. Does a merchant have a special store available because a PC has completed a long and complex quest arc? You can do that-- make two merchants, and two branches of conversation available. Put NPC responses under conditionals, just like you did in the Hook section, but this time we want nState to be or whatever the finished journal number is, instead of 0. Do you want a few quests to be done in order? Also doable-- just check for two conditionals:

In this example, this conversation option is only available of sample_quest_0 is nState of 3 (which is finished, if you've been following our especially-simplistic example) and sample_quest_1 isn't started. We could put the rest of our hook down this conversation line and thus have the two operate as a chain, and you could do it again with this quest once it's done (and so on).

Finalizing the Quest

Once you're done, don't forget that there's an XP field in the quest journal. You'll want to run your quest yourself to see how long it takes and how much it should reward. At the time of this writing, the standard was to award 25 xp per CR, assuming that the static takes about an hour-- but use your good judgment. If it feels like it's rewarding too much like that, it's usually safer to reward low than high: a quest that rewards too low doesn't get done as often as we like, but a quest that rewards too high disrupts play for the server. Once you have a value, it goes into the journal category, where you should have put a low number as a placeholder during your hook writing.

Main Page -- Hook -- Challenge -- Turnin

When determining the challenge portion of an ACR quest, the thing to keep foremost in one's mind is how you're going to advance the state of the quest. This page assumes that you've already set up a quest Hook that initializes the quest. The challenge portion of a quest is also the easiest to combine or repeat-- by simply adding more states that the quest must pass through before it's considered completed.

Conversation Challenges

When writing a challenge that operates through a conversation, we will again be creating a conversation tree-- we'll need a conversation option somewhere for the player to bring up the quest they're on, and some responses to indicate what the player needs to do next.

Like with the hook, we'll need to have a conditional statement to check if the conversation option should exist, but this time it will go on the player's broaching of the topic ("Hello! I have gotten going" in the example above). Just as before, click on the node, then the condition. Again, you'll want to use acr_quest_progress, and the same sQuest, but this time we don't want nState to be 0 (because 0 means that the quest isn't started) -- now we want it to be 1. That tells us that the character is on the quest-- moreover, it tells us that the player is on this step of the quest.

Once that is done, we move on to the NPC's response (in this case, "So I see! You should go back to...") -- we want to update the quest state so that we know the PC has spoken to the target of the quest, so we'll be on the actions tab. But because we're not starting a quest this time, we'll be using acr_quest_update. In this case, we're just advancing the quest-- so we want the same sQuest we've been using, but we want to set nState to a whole new number: in this case, 2. bAllPartyMembers is, as always, the question of whether or not doing this should advance the quest for everyone.

Now, we accomplish a few things when we do this.
1. Remember the quest giver? He wants nState to be 0 to give the quest, so he won't restart the quest, or offer to, when the player goes back.
2. Remember the conditional we set up on this conversation? It wants nState to be 1, so we can't repeat this step of the quest.
3. nState being 2 is a unique number, so we can use it to configure our turnin later.

After you've done that, open the journal and add an entry to this quest's category, number it 2, and give it a description that explains what they would believe they need to do next.

So with that done, it's time to test. Start up a server and try it out. Make sure that you don't get quest conversation points when you don't have the quest, but that you do if you've taken the quest and can't repeat the step.

Of course, this doesn't sound very challenging-- the first thing to point out is that this person probably isn't going to be standing next to the quest giver; he might be far away, hard to find, in a dangerous locale, or all three. But if that's not enough, we can also set up another level of difficulty here. First, we'll need to expand our conversation tree to allow us to have other checks happening-- and maybe let the character pick how they solve whatever problem it is.

In this example, moving nState 1 to 2 requires some avenue to convince the quest giver that progress is acceptable. We'll leave the scripts on "Hello! I have gotten going" from the previous example, so that we know that we're only dealing with people who are on the quest, and then we need to concern ourselves with the skill checks. So, let's take the first option-- a Perform (Dance) check. We leave the player option there without any scripts. Anyone can try to dance. You only need training to be good at it.

So we have two NPC responses to the attempted dance, the same way that we did when we were asking the hook NPC for work. On the first response ("All right, you win" in the example), we're going to set our skill check:

We're using acr_cs_skcheck, which will roll nSkill against nDC. nSkill is a constant, and simply needs to be looked up, while nDC is the minimum roll that 1d20 + skill modifier must be to pass the check.

Once this is done, we can place the action on the player response ("Yay" in the example above) that we had on the simpler quest setup, to set nState to 2.

Now we're stuck with the question of what to do if the check fails. It's very easy for a player to just mash buttons through conversations until they pass a skill check, so it's usually wise to provide some sort of failure state in these sorts of quests. Add an action to the player's response to the failure conversation ("You suck!") that sets nState to something else-- it can be any number, as long as it's unique-- and write a journal entry that describes the failure (and, if you like, you can provide some challenge-type interaction that looks for the quest's failure state and resets it-- such as bringing this NPC flowers and an apology; such would follow the same pattern as here).

Now, the other three checks would follow very similar patterns-- but let's have a look at that second one. Tumble requires training. Most characters would know that they can't impress anyone with tumble. Of course, the players probably know that too, but if we're nice builders, we'll just never show non-tumbling characters the option to tumble their way to victory. It's a little mean, after all; they're promised to fail if they try.

So what we'll do is put a conditional on the tumble option-- just like before, but we'll be using gc_skill_rank as our conditional. Now, the prefix ("gc_") tells you that this script is only meant for Obsidian resources, so we wouldn't be able to use this on Perform(Dance) like we did with the acr script, abut it's perfectly functional for checking if a player has ranks in tumble. So, we'll pick the script and refresh, as before, but because this is an Obsidian script, we're going to want to read the comment lines on the script (that is the green text that appears in the box when you have the row highlighted). It tells us that:

int nSkill = skill int to check
int nRank = minimum rank to return TRUE

But notice that right below that, it tells us what integers refer to which skills for this script. So tumble is 26 here, even though tumble's constant is 21. Quirks like this are why it's important to read those comment lines on any new script-- most people who write them are trying to help you by writing them.

So we'll set nSkill to 26, and nRank to 1. This way, the tumble check will never be an option for a character who can't tumble.

There are a number of scripts that you can use in this way, and the comment lines will generally tell you how (and the names will give you hints). You can click the down arrow beside the entry field for a script to pull up a searchable list-- for conditional scripts, scripts starting with "acr_cs_" and "gc_" are valid for use. The acr_cs_ scripts are those that ALFA has assembled for itself, and are usually the best place to look for anything that is specific to us (such as checking a player's progress on a quest), while the gc_ scripts cover a number of universal concepts that wouldn't need any special handling (such as gc_is_female, which is exactly what it sounds like)

Trigger Challenges

Perhaps this quest isn't meant to be completed through a conversation or an interaction with an NPC. It is possible that the challenge is in arriving at some destination, retrieving some item, or slaying some sort of threat. Generally speaking, these sorts of quests are completed with triggers. The first step is going to be setting a new trigger. In the triggers tab of your blueprints panel, find the Quest OnEnter trigger template, and draw it on the ground where you wish the quest to be completed. As with the placement of any trigger, each click will add a new corner to the trigger, and as the basic rules of geometry declare, you need at least three corners to make a shape with straight sides (and circular triggers can't be drawn; there are only polygons with many sides).

Now select the trigger you just placed (the "Select Objects" button on your toolbar will allow you to select objects, instead of painting more corners on your trigger). View the properties of the trigger and find the "Scripts" subsection of the trigger's properties.

You'll first want to verify that the acf_trg_ series of scripts are in use on the trigger, and that the name of each script matches up with the event that it is placed on. acf_trg_onenter in the On Enter Script field, for example. Once that is set, click into the "Variables" field and then click on the "..." button on the right side of the field. This will open the variable editing window. At this point, we branch slightly based on what we want this trigger to do:

For All Quest Triggers

Identify the Quest: First, every quest needs to be identified by its tag, which you defined originally when you created the hook for this quest. This is set on ACR_QST_NAME as a string, like this:

Identify the Prerequisite State: Every quest needs to know what you expect nState to be when a player on this quest enters the trigger. By default, this is set to 1, assuming that nState was set to 1 in the initial conversation. However, if you have a more complex quest (Bob says to talk to Harry, who tells you to check on the tree at the top of the hill and come back to him), you might need to change this. The value is stored in ACR_QST_LOWER_STATE, and is an integer (and so may be set in the ValueInt field, like this:)

Identify if This Finishes the Quest: Every quest also needs to know if visiting this trigger provides the reward for the quest. This is set in ACR_QST_UPPER_STATE. If you don't want the trigger to reward experience (if, for example, the rewards will be present when the PC returns to the quest giver), this should be set to 0. If you do wish to reward XP, this should be set to one higher than ACR_QST_LOWER_STATE. It is also an integer, and editing it looks exactly as ACR_QST_LOWER_STATE.

For Scouting Quest Triggers

That's it. You've written this challenge. When a PC visits your trigger and nState is ACR_QST_LOWER_STATE, they will get a journal entry and an nState of one higher. So if ACR_QST_LOWER_STATE was 1, they leave with 2, and you may check for that at the turnin.

For Combat Quest Triggers

You'll need to tool a creature for the PC to fight. Once this is done, you'll set two variables: ACR_QST_SPAWN_CRESREF is set to the resource name of the creature you wish to spawn. Important: Resource Names and Blueprint ResRefs are not necessarily the same. To prevent confusion, you should tool your creatures to always have the same ResRef as Resource Name.

Next, you will set the value of ACR_QST_SPAWN_WAYPOINT to be the unique tag of a waypoint at which your creature will spawn. Usually, this is near or inside of the trigger that is being tooled. Because this needs to be unique, you should pick a tag that is unlikely to be used by anyone else in the future-- usually appending "_spn##" to the quest's tag is a reliable way to ensure as much. In this case, it would be "sample_quest_0_spn01"

With that done, your quest is ready. As with a scouting quest, nState will be 1 higher than ACR_QST_LOWER_STATE, once the creature is killed. For example, if ACR_QST_LOWER_STATE is 1, you should check for nState to be 2 at the next step of the quest.

For Retrieval Quest Triggers

If your quest is a retrieval, you have two more variables to set and one more thing to place. First, you will need to pick a unique tag for a container for your retrieved thing. You don't need to style it like a box or a bag-- it can, for instance, be a hollow tree trunk or a shallow hole, but you'll be tooling it like one. Because this needs to be unique, you should pick a tag that is unlikely to be used by anyone else in the future-- usually, appending "_cntr##" to the quest's tag is a reliable way to ensure as much. In this case, it would be "sample_quest_0_cntr01"

First, create a new string named "ACR_QST_CONTAINER_TAG" and set its value to your unique container tag.

Next, we will want to pick what sort of item will appear in this box. Tool a new item with a new resource name and flavor text to represent the object being retrieved-- and be sure to consider if the item itself is to be part of the challenge (it might apply penalties to the PC, or might be especially heavy, for example). Then create a new variable named "ACR_QST_SPAWN_IRESREF" which has the same value as the item's Resource Name. Important: Resource Names and Blueprint ResRefs are not necessarily the same. To prevent confusion, you should tool your items to always have the same ResRef as Resource Name.

Finally, we need to place a container which has the tag we set in ACR_QST_CONTAINER. Place a placeable in the area (usually near or in the trigger) and ensure five features:

1. The container has no scripts on it
2. The container is set to plot
3. The container has an inventory
4. The container's tag is the one you specified before.
5. The container is empty

As with scouting quests, the item will appear in the chest only if a character whose nState is at ACR_QST_LOWER_STATE enters the trigger, and nState will advance to the next number once they pick up the item (so a 1 becomes a 2, for example), which can be checked later to drive further challenges or a turning.

Placeable Challenges

TODO: Describe how to set up a placeable-based quest challenge

#39;ll need to expand our conversation tree to allow us to have other checks happening-- and maybe let the character pick how they solve whatever problem it is.

Main Page -- Hook -- Challenge -- Turnin

The Hook to the quest is usually primarily the human-readable portion-- you will need to write something that players will read, either a bit of exposition, a description of some sort of object, or a conversation to be run through.

Quest Hooks in Conversations

The conversation quest hook is by far the most common sort of hook. Generally speaking, static quests take the form of performing some task for someone else, and the players need to ask that person for work to be given an assignment, and return to that person to be paid. Conversation tutorials are best handled elsewhere. Here, we're most interested in two parts of the conversation: the conditional to see if it's the right time to start the quest and the action.

First, find the conversation nodes for the NPC's response to the PC asking for work and add two responses, one for explaining the task and one for shrugging off the request. In response to the NPC describing the quest, we generally give the PC the option to accept or decline the task, and then have some agreement from the NPC.

Once you have that, select the description (in the example above, that would be "OK, do this thing?") and look near the bottom of the screen, where the tabs are (3) and select Conditions. There, you can add a condition.

In the added condition, specify acr_quest_progress (1), and then click refresh.

Once this is done, places to specify sQuest and nState appear. sQuest is something you pick-- it needs to be unique per module, but other than that it can be anything you want. This is the quest's "name" for other purposes that we'll be talking about, so either write it down or be ready to come back to this conversation to verify what the quest's name is.

In the nState field, set it to 0. This is the state of a quest that hasn't been started yet.

With this in place, you've specified that the NPC will only speak the first line (describing the job) if the quest you've specified is in state 0 (that is, not started). You can add more lines if you'd like more conditions for this, but it's best to keep your first one simple.

Next, you'll want to select the PC's conversation option to accept the quest, (In the example above, "Yes, I would love to do that thing!") and find the Actions tab in the lower portion of the conversation.

Here you'll specify the script as acr_quest_update, and then refresh. You'll get three parameters this time: sQuest, nState, and bAllPartyMembers.

sQuest needs to be the same quest name that you'll be using repeatedly. nState is arbitrary-- it needs to be a number, it can't be zero, and you'll want to remember it (because we're going to use it to set up the journal too). bAllPartyMembers determines if everyone in the speaker's party gets the quest; 0 means no, 1 means yes.

Finally, open your module's journal (view > journal > module). Find the Add Category button near the top and set the journal entry's tag to be the quest's name. Then set its name to be something human-friendly. This will be the name that appears in the quest's header inside of the player's journal. You can also specify a quantity of XP here, though it's usually best to set it to something fake and low until you've tested your quest, and know how long it takes and how hard it is.

Finally, select the category you've created and find the Add Entry button near the top of the journal. This will make a tree node under the category. Select it, give it the same ID that you set nState to with acr_quest_update (above) and type a description of the quest (as understood from the in-character perspective) into the description field.

And thus you've written enough to get the quest started. Test it out-- start up your build module, log in, and talk to this NPC. See if you get a journal entry about your quest. Then talk to the NPC again and ask for work. Make sure that you don't get offered the same job again. If it works, success! Move on you building your challenge.

Fed-Ex / Courier Quests

Some quests, which follow a very similar pattern to this, you'll want the character to carry and item to the destination. While there are many ways to do this, the one that is the most effective for the model is acr_quest_escort. This has two strong advantages over generic item creation scripts:
1. It will flag the item it makes as part of the quest the player is on
2. It will initiate the quest, assuming that nState is 1 when the quest starts.

To do this, you'll want to set up your checks like you did before to prevent people from restarting the quest (so make sure that the quest's nState is 0), and you'll need a journal entry the same as above so your players can keep track of the quest.

The parameters, however, will only be sQuest and sTemplate. sQuest will contain the quest name, which you'll need to keep track of and re-use throughought the building process. sTemplate is the blueprint resref of the item you're seeking to deliver. The quest will assume that it isn't applying to an entire party and it will assume that the quest started state is nState = 1, which you'll need to check for later.

Quest Hooks on Triggers

TODO: explain how to put a hook on a trigger here

Quest Hooks on Placeables

TODO: explain how to put a hook on a placeable here

Main Page -- Hook -- Challenge -- Turnin

Static quests are a common strategy to provide less-complex and less-rewarding entertainment for players while there are no DMs online. Ideally, these quests should facilitate role playing by presenting players with a goal that they can pursue for some period of time.

This tutorial will try not to assume and pre-existing knowledge, but will also attempt to link away to other pages to provide definitions that more-proficient users are likely to find cumbersome or extraneous, with this page providing the broadest outline, and links which can be used to view greater detail on the individual parts.

Writing a quest generally begins by defining your task. Take a moment to write, as a paragraph or so, what you want characters to have to do in this quest. It can be vague or open-ended, but projects are vulnerable to scope creep if they don't have a goal when they begin.

Once this is done, it comes time to divide your quest into its requisite parts:
The Hook: represents the introduction of the quest to the players involved; something is done to inform the PCs that they have a task to accomplish.
The Challenge: represents the actions that the players have to take to consider the quest done.
The Turnin: represents how the players are rewarded for completing the chosen task.

Take, as the simplest example, a courier quest:

• The Hook: when the players present to whoever is offering courier work
• The Challenge: the travel to and from the recipient of the package
• The Turnin: speaking to the employer for payment

However, these quests can be infinitely recursive. Take, for example, a quest to catch a bothersome and powerful criminal entrenched in a city:

• Players seek work for the city, and are provided with a series of lower-risk tasks, which uncover something far bigger and more siniser afoot:
  • Primary Hook: Evidence speaks of bad guys who need busting up.
    • Players recover low value contraband from the bad neighborhood
      • Hook: Present to Commanding Officer
      • Challenge: Fight or intimidate street thugs to give up the goods
      • Turnin: Bring the contraband back to the C.O.
    • Players carry a message to a guardsman on duty
      • Hook: Present to C.O.
      • Challenge: Find guardsman and present message
        • Hook: Guard has gone missing! Bloody hell!
        • Challenge: Skulk through the sewers to follow the guardsman's still-warm trail
        • Turnin: Find unconscious guardsman and revive. Present message
      • Turnin: Return to C.O.
    • Players Seek Investigation
      • Hook: Present to C.O.
      • Challenge: Return to the missing guardsman's trail to investigate circumstances. Find evidence of organization
      • Turnin: Bring evidence back to C.O.
  • Primary Challenge: Bust up some Bad Guys
    • Players find guardsmen who may have seen activity
      • Hook: Talk to three guardsman to be directed to the most-troubled parts
      • Challenge: Speak to all of the guards in the troubled area to get hints into the sorts of criminal activities done.
      • Turnin: Return to C.O.
    • Players bust up three operations:
      • Operaton 1: Street dealer
        • Challenge: find out where a dealer of whatever bad stuff (above) is working. Track and capture him.
        • Turnin: Bad guy -> Jail
      • Operation 2: Ships
        • Challenge: correctly identify and search a ship full of whatever the bad stuff is.
        • Turnin: Bad stuff -> C.O.
      • Operation 3: Storage
        • Challenge: find the avenues being used to move the bad stuff around the city.
        • Turnin: Bring information back to C.O.
    • Information gained from three operations directs to a likely location for a center of bad stuff in the city. Players bust in and bust things up, probably dealing with heavy resistance and hazardous settings.
  • Primary Turnin: Return to the C.O. and get money or a promotion or something.

And there is demonstration there that you can have quests within quests within quests: using one's quest's completion as prerequisite to the advancement of another arc-like quest, or how you can have sequences of checks or actions (potentially unrelated actions) be required to progress the quest to its next step: and those quests can themselves be complex, if the circumstances require. Ultimately, though, it does need to be boiled down into nests or sequences of simple things before it can be built.

Links:
Hook -- Challenge -- Turnin

These textual commands require at least ACR v1.90.

Understanding Text Commands

The text commands presented on this page carry different formatting. Text in Courier New are actual text commands, meant to be typed. Often, to explain what a command does when there are multiple displayed at once, an inline comment will be given. This is not meant to be typed.

For example, if the page says:
#subdual // Toggles subdual mode.

It means that you type #subdual only. Additionally, some parameters are user defined, and must be filled in by the user. Content inside <brackets> should be replaced with actual content.

For example:
#tradescroll <Spell ID>

The above command means you should type in the ID of the spell to make a tradescroll for (such as #tradescroll 3113 to make a tradescroll of water breathing).

Targets

By using certain text inserts, you can define the target for your command. Valid target definitions are:

$self
$target
$companion
$<object ID>

For example, to progress crafting on your currently selected item, you could type:
#craft $target

The Commands

Subdual Mode

Subdual mode can be set or toggled via a text command. Valid uses:

#subdual // Toggle subdual mode.
#subdual on // Set subdual mode on.
#subdual off // Set subdual mode off.

Manage Spells

Functionality under development.

Prepare Spells

Preparing spells can now be done via text commands. Valid uses:

#pray
#spellbook

These commands have you pray for spells and memorize from your spellbook respectively.

Craft

By using text commands, you can progress crafting on an item or open a crafting store.

To open a crafting store:
#craft scroll
#craft potion
#craft wand

To progress crafting on an item, you must first select that item, then type:
#craft $target

Create Tradescroll

Text commands can create tradescrolls. This helps when a spell isn't normally able to be cast on a spellbook. Usage:
#tradescroll <Spell ID>

You may need to research the spell's ID from the ACR's spells.2da.