Commands

All commands can be found under the /q,quest base command.

Player Commands

• l,list
  [page=1] [incomplete/complete/all=incomplete] list your quests
• s,show [node=used] show a quest or objective
• u,use [node=check] use a quest
• v,version see plugin version

Author Commands

• n,nodes [page=1] [all/decendants/children/sibilings=all] list nodes
• i,inspect [node=used] inspect a node
• c,create <id> create node
• delete [node=used] delete node
• e,edit
  • i,id <id> set new id
  • n,name <name> set new name
  • d,desc <desc> set new desc
  • c,category <category> set new category
  • v,visible <visible> set new visible
  • t,times <times> set new times
  • co,cooldown <cooldown> set new cooldown
  • tf,tofind [rule=list] [data] edit tofind
  • ta,toadvance [rule=list] [data] edit toadvance
  • of,onfind [rule=list] [data] edit onfind
  • oa,onadvance [rule=list] [data] edit onadvance
  • oc,oncomplete [rule=list] [data] edit oncomplete
  • l,locked <locked> edit locked
• r,rule
  • l,list [page=1] list rules
  • s,show <rule> show rule
• p,progress
  • l,list [page=1] [player=you] list found node progress
  • f,find [player=you] [node=used] find node
  • u,unfind [player=you] [node=used] unfind node
  • ut,unfindtree [player=you] [node=used] unfind node and all of it’s decendants
  • a,advance [times=1] [player=you] [node=used] advance node progress
  • c,complete [player=you] [node=used] advance node progress completely
  • s,set <times> [player=you] [node=used] set node progress
• t,tool
  • clean remove progress entries for deleted quests
  • todo converts all ToFind into DoFind where possible
  • ntlcompile compiles all NodeTraversalLanguage into plain node ids

Permissions

• Rank0 (normal players) can’t even see the author commands.
• Rank1 can see all commands and have read only access.
• Rank2 can do everything but lock and unlock nodes.
• Rank3 can lock and unlock nodes.

The Node

What is a “node”? The node is the sole quest building block from a data perspective. These are the fields:

Field	Type	Edit Command	Description	Example
ID	Text	/q e i <id>	The formal database id.	example.talktosteve
Name	Text	/q e n <name>	A nice name for humans.	Talk to Steve
Desc	Text	/q e d <desc>	What’s this quest about? What’s the objective?	It’s raining today. Go inside and talk to Steve. He will give you a cake.
Category	Toggle	/q e c <category>	Is this node a quest category?	false
Visible	Toggle	/q e v <visible>	Is this node visible to the quester?	true
Times	Number	/q e t <times>	How many times must this node be advanced for completion?	1
Cooldown	Time	/q e co <cooldown>	How soon after completion can this node be completed again?	5days1min40seconds
ToFind	Rule+Data…	/q e tf [rule=list] [data]	Rules that must apply to find this node.	onenterworld regalia ifrain
ToAdvance	Rule+Data…	/q e ta [rule=list] [data]	Rules that must apply to advance this node 1 time.	onclicknpc Steve ifinworld regalia
OnFind	Rule+Data…	/q e of [rule=list] [data]	Rules to apply upon finding this node.
OnAdvance	Rule+Data…	/q e oa [rule=list] [data]	Rules to apply upon advancing (but not completing) this node.
OnComplete	Rule+Data…	/q e oc [rule=list] [data]	Rules to apply upon completing this node.	docmd /give {p} cake 1
Locked	Toggle	/q e l <locked>	Is this node locked? Locked nodes and their descendants can’t be edited.	true
Authors	Player…	automatically updated	What authors have edited this node?	Cayorion MonMarty

The Tree Structure

MassiveQuest looks at the dots in the node id and interprets this as if the nodes were in a tree structure. This is done by looking at the dots in the node id. The node id is always in lowercase letters and has parts separated with dots. For example “example.talktosteve“, “etosil.undead.deforestation” or “test.cayorion.hah.300“. Let’s learn some terminology for tree structures:

• child: The node “asdf.herp.derp” is a child to the node “asdf.herp”. The node “asdf.herp.derp” is however not a child to the node “asdf”.
• parent: The node “asdf.herp” is the parent to the node “asdf.herp.derp”. The node “asdf” is however not the parent to the node “asdf.herp.derp”.
• descendant: Both “asdf.herp” and “asdf.herp.derp” are descendants to the node “asdf”.
• ancestor: “asdf” is an ancestor both “asdf.herp” and “asdf.herp.derp”.
• sibling: “asdf.herp”, “asdf.frood” and “asdf.kakaa” are siblings.
• root: “asdf” is a root node since it contains no dots.
• orphan: A non-root node whose parent do not exist is called an orphan. The node “blipp.blopp” is an orphan if “blipp” does not exist.

NOTE: Don’t create orphans! Make sure to create the required ancestors. The way MassiveQuest is designed orphans make no sense.

A node is either a Category, Quest or Objective. To make a node a category you have to edit the Category Toggle using /q e c true. If a node isn’t a category it’s either a Quest or an Objective. A child to a category node is interpreted as a quest and the rest are interpreted as objectives. Quests and Objectives are pretty much the same thing though. We could have called Objectives Sub-Quests instead.

ID Standards

We have a ID standard for Categories. The root categories (the very top ones) must always be world names. If a quest starts in Etosil it should be put somewhere under the “etosil” category. As for the sub categories we should try to categorize based on a more fine grained location or possibly what “faction” hands out the quest. This is an example proposed category layout for the etosil island where the undead and alive are having a civil war:

• etosil – the root category node for the world Etosil.
• etosil.alive – sub category for helping the alive side in the civil war.
• etosil.alive.tavern – sub category for quests handed out in the city tavern.
• etosil.alive.guard – sub category for quests handed out at the city guard barracks.
• etosil.undead – sub category for helping the undead side in the civil war.
• etosil.undead.manor – sub category for quests handed out at the manor.
• etosil.undead.graveyard – sub category for quests handed out at the graveyard.

We also have an ID standard for Quests and Objectives. Quests are named after some abbreviation or short form of their name. The quest called “The Missing Guardsman” could have id “etosil.alive.guard.tmg”. The Objectives of the Quest are using numbers with multiples of 100 like this:

• etosil.alive.guard.tmg – The Missing Guardsman – Sir Erik left to patrol the western side of the island three days ago, and hasn’t returned.
• etosil.alive.guard.tmg.100 – Search the western side of the island – Since that’s where he said he would go it makes sense to start the search there.
• etosil.alive.guard.tmg.200 – Report back to Officer Robin – Erik was found dead. Bring the sad news to Officer Robin.

Command Basics

/q list VS /q nodes

The player command /q l,list [page=1] [incomplete/complete/all=incomplete]
has the author equivalent /q n,nodes [page=1] [all/decendants/children/sibilings=all]

Both those commands list nodes. The player one lists the nodes from the perspective of the player. That means you will see only nodes you found when using /q l. Additionally it will show you your progress. As an author you want to all nodes regardless of whether you found them or not. You also want more technical information. This is what /q n is for.

HINT: Is your node showing up in red color in /q n? That means it’s an orphan. You should create the missing quest categories!
HINT: What does the C D S letters in /q n stand for? Children, Descendants and Siblings.

/q show VS /q inspect

The player command /q s,show [node=used]
has the author equivalent i,inspect [node=used]

Both those commands view info for a certain node. Just like list and nodes; show and inspect will show you the player and author side of the same coin. /q i is your best friend! You will use it a lot when writing quests. When inspecting you will see all the system details for the node.

Node arguments and /q use

Many of the commands take a node argument. It’s usually [node=used]. What does that mean? First of all the square braces “[]” indicates that the argument is optional. If you don’t supply one the node you are currently “using” will be assumed. You can select one node for use at a time. This is done with /q u,use [node=check]. You can use either node id or name meaning both these would work:

• /q u etosil.alive.guard.tmg
• /q u the missing guardsman

And now for an advance feature: relative node id selection. Say you have selected “etosil.alive.guard.tmg” and you want to select the parent “etosil.alive.guard”. You can type “/q u ..” to achieve that. Double dot means the parent node of the currently used node. Say you are using “etosil.alive.guard” and you want to use the child node “etosil.alive.guard.200”. You can type “/q u .200” to achieve that. These features can be used for any command and not only /q u. You want to inspect the parent of your currently selected node? Just go ahead and type “/q i ..“.

Commands for editing

Use /q c,create <id> to create an new node. Upon creating a new node it will automatically be selected for use.

Use /q e i,id <id> to change the id of the selected node. It’s basically a search and replace feature that looks over all MassiveQuest player and node data. For this reason it’s a bit performance heavy and slightly error prone.

Per default the name will be set to the id. That’s boring as hell. Your first order of business is to give the node a proper name using
/q e,edit n,name <name>

NOTE: None of the edit commands takes a node argument. They all operate on the currently used node.

Your second order of business is to give the node a description using the /q e,edit d,desc <desc> command. This step is actually optional. Nodes don’t need a description. The output from /q s can at times look cleaner without descriptions on everything. Use /q e d null to remove the current description. Some times you want the opposite though! You want a really long and elaborate description. In those situations it may not fit into the chat input. The solution is to use the MassiveCore variable system. The <br> tag can be used for line breaks like in this example: /q e d paragraph one<br><br>paragraph two.

Use /q e,edit c,category <category> to set the category toggle for the used node. Use either of these:

• /q e c true
• /q e c false

Next up is /q e,edit t,times <times>. The “times” field is a number. It could be 0, 1, 2, 3, 4 etc. Per default it’s 1. The times field decides how many times the node must be advanced in order to be completed. You want the player to have killing 10 zombies as an objective? Set times to 10! You want a node that is completed at once it’s found? Set times to 0! Nodes with times 0 are purely informational nodes. They are commonly placed at the end of a quest to have a nice summary message appear.

Use /q e,edit co,cooldown <cooldown> to set the node cooldown. If you want a 1 day cooldown you should type /q e co 1day. If you want to remove the cooldown you should type /q e co null. Cooldown is usually null. What does the cooldown do? Upon completing a node with cooldown a timer starts and once the timer rings the node and all it’s children are unfound, then the node is found again. Basically all quest progress is erased and you can do the quest again as if you just found it. If you want the quest to be repeatable but without a cooldown you can use /q e co 0.

And now it’s time to bring out them heavy gunz!!! Lets take a look at the rule commands:

• /q e,edit tf,tofind [rule=list] [data]
• /q e,edit ta,toadvance [rule=list] [data]
• /q e,edit of,onfind [rule=list] [data]
• /q e,edit oa,onadvance [rule=list] [data]
• /q e,edit oc,oncomplete [rule=list] [data]

With these commands you manage rules. Say you want the player to find the quest upon clicking an NPC called Officer Robin.
You would type: /q e tf onclicknpc officer robin. Say additionally you must also be a premium member to get the quest when clicking Officer Robin. You would type /q e tf ispremium. Say you forgot what rules you added? Just type /q i to see all info. The current rules would be:

1. onclicknpc officer robin
2. ispremium

You want to delete the ispremium rule? Type /q e tf #2. That will delete the second rule.

Rules

There are three types of rules:

1. Triggers – these rules start with “on” like “onclicknpc”
2. Requirements – these rules start with “if” like “ifpremium”
3. Actions – these rules start with “do” like “doloseitem”

Use /q r,rule l,list [page=1] to list the available rules.
Use /q r,rule s,show <rule> to show more info on a specific rule.
You can also find all the available rules further down on this page.

We use the term “apply“. A rule either applies or it does not. Only one trigger can apply at a time. If you click the npc called officer robin the rule “onclicknpc officer robin” would apply during an instant. Multiple requirements can apply at a time. It’s perfectly possible for “ifpremium” and “ifrain” to apply at the same time. They would apply for any premium member standing in a world where it’s raining. Actions always apply. It’s 100% impossible for a rule to not apply. An action will try to carry itself out and it’s the attempt that counts. In rare cases actions might fail somehow but we don’t give a shit. They apply anyways.

Multiple rules together form what we call a “rule set“. The files tofind, toadvance, onfind, onadvance and oncomplete are all rule sets. A rule set applies if and only if all rules within applies. Another way to describe this is that the rules are connected with AND operators. There is no OR functionality within a rule set.

Example: The ruleset [“onclicknpc officer robin”, “onclickblock”] can never apply since only one trigger can apply at the same time. It’s impossible to both click an npc and a click a block in the very same atomic time instance. You can first click an npc and then very shortly after click a block but that is not the same thing as doing it at the same time.

Example: The ruleset [“docmd /give {p} 1 cake”, “doloseitem 17×20”] will always apply since it only contains actions. Uppon trying to apply this ruleset for a player the player would get a cake and lose 20 logs.

Example: The ruleset [“onclicknpc officer robin”, “ifpremium”, “ifhasitem 17×20”, “doloseitem 17×20”] will apply if
the player is clicking an npc called officer robin AND
the player is premium AND
has 20 logs in their inventory AND
20 logs get removed from their inventory (this will always succeed since it’s an action)

The rulesets tofind and toadvance should usually contain one trigger each. The rulesets onfind, onadvance and oncomplete are fired when the node is found, advanced or completed. Those rulesets should not contain any triggers but rather actions and perhaps a few requirements.

If you want a rule to apply when it doesn’t you can prefix it with “!”. The rule “!ifrain” will apply when it’s not raining.

Node Advancement

A player…

• … can only find nodes that she have not found yet.
• … can only advance nodes that she have found and not completed yet.
• … will complete a node when it’s advanced as many times as it has “times”.

Node Traversal Language

MassiveQuest comes with a node traversal language that can be used any time you supply a node as a command argument. It can for example be used in the /q use <node> command (where the origin is your currently used node) or in combination with an OnFind rule (where the origin is the node you add the rule to).

These are the operators:

• . Self
• > First Child
• < Parent (takes times modifier)
• << Root
• + Next Sibling (takes times modifier)
• ++ Last Sibling
• – Previous Sibling (takes times modifier)
• — First Sibling

See the example quest below for usage examples.

Example Quests

Perhaps these example quests will help you understand :)
We assume that the parent categories “etosil”, “etosil.alive” and “etosil.alive.guard” are already created.

The Missing Guardsman

Let’s take a look at the command sequence to create the quest “The Missing Guardsman“. This quest starts at the NPC Officer Robin who is standing at the guard barracks. He will ask you to search for the missing guardsman on the western side of the island. The sad truth is that he is dead and when you find his corpse you report the sad new back to officer robin.

This is a simple quest in the sense that we only used trigger-rules. The “OnEnterRegion etosil.guardcorpse” assumes that we have set up WorldGuard region around the corpse. Did you understand what the last two commands are for? We advance/complete the quest itself when we complete the last objective in the quest. Similarly we find the first quest objective when we find the quest itself.

The Missing Guardsman (with NTL)

This is the missing guardsman quest again. This time however we make use of the node traversal language.

The following node traversal language was used:

• > to match the first child node (for finding the first objective upon finding the quest itself).
• + to match the next node (for finding the next node upon completing the previous one).
• < to match the parent node (the advancing/completing the quest itself upon completing the last objective).

Defend the Gates

Let’s take a look at the command sequence to create the quest “Defend the Gates“. You get this quest when you finish “The Missing Guardsman“. The undead are attacking the city gates. You are to go there and slay some zombies and skeletons. Additionally you must deliver some bones to NPC Officer Robin to get your contribution approved.

This quest was more advanced. You get both of the objectives “Kill Zombies” and “Kill Skeletons” at the same time upon arriving at the city gates. Both of these make use of the “times” field to denote that you need to kill 10 zombies instead of just only one. To get the final objective you must have complete both “Kill Zombies” and “Kill Skeletons”. This is done by using the the IfCompleted rule two times. Note that we did not use OnComplete rules. Having two triggers is as previously mentioned not allowed but having two requirements is fine. Note that you should use OnComplete where possible. To finish the last objective you need to click Officer Robin while carrying 5 bones. Upon completing the last node you will lose 5 bones.

The following node traversal language was used:

• > to match the first child node (for finding the first objective upon finding the quest itself).
• <.200 to match the sibling node ending with .200 (to get the two objectives).
• <.300 to match the sibling node ending with .300 (to get the two objectives).
• -1 to match the previous node (an objective).
• -2 to match the second previous node (an objective).
• < to match the parent node (the advancing/completing the quest itself upon completing the last objective).

Trigger Rules