Denizen/0.6

External Character Type!
This page is about a type of NPC that is not developed supported by the Citizens development team. Don't ask for support from them, or on the forums/IRC, as we won't be able to help you. Instead, look at the BukkitDev link of the InfoBox to the right for information on how to get support for this character type.

Denizen Author aufdemrand Version 0.5 Citizens build 2.0 Newest Dev Development status InDev Download [ Link] BukkitDev [ Link] Source Link Issues Link Description: Denizens are helpful, interactive Citizens! Installing Character Types

Denizens are a great way to add MUD-style RPG Citizens (and some other features) to your server. Denizen NPCs use mini scripts with steps and events to interact with the player and world. They can be used in hundreds (thousands?) of different ways, from tutorials, to questing, to administrating and more!

Denizens are in BETA! Expect bugs, and if you would be so kind, please report them to the Github Issues page for Denizens. You can also get assistance with Denizens on the #citizens IRC channel on EsperNET from me (aufdemrand) when available. I'm working hard to add awesome features and to squash any bugs, but here's the tentative timeline I'm trying to follow.

Timeline:
Beta 1 -- All functionality used in the example file.
Beta 2 -- Additional functionality of additional behaviors/requirements/triggers listed.
1.0 -- Bug fixes from Beta.
1.5 -- Standalone (Window) script writer.
2.0 -- Profit.


How do Denizens work?

There are lots of cool things that the Denizens plugin has to offer, but let's start with the basics. YAML scripted NPCs.

A basic script

First, we need a script. Scripts can be simple or very powerful, thanks to a wide array of commands and functions at your disposal. Each script has at least 2 parts, Requirements and Steps. For now, let's take this very simple script as an example. We'll get more detailed later on.

Scripts are defined in the Scripts node found in plugins/Denizens/config.yml

Scripts: 
  'Daytime in the City':   
    Requirements:
      Mode: All
      List:
        - TIME Day
    Steps:
      0:
        Click Trigger:
          - CHAT Welcome to the city! Isn't it beautiful in the daytime?

So what just happened there? A quick literal translation: This script is named 'Daytime in the City'. This name is used when assigning Denizen NPCs their scripts to use. When the script is called by a trigger, in this case a 'Click Trigger', for it to activate the Requirements set must be met, more specifically ALL of the requirements set. In this example, the only requirement is that the time in the world is daytime. If the Requirements are met, the script defined in the 'Click Trigger' is sent to be run. It will have the Denizen NPC chat to the player 'Welcome to the city! Isn't it beautiful in the daytime?'.

But before the script can be triggered, it needs to be assigned.

A basic assignment

In order for a Denizen to be associated with a script, he needs to be assigned to it. The following shows a simple assignment format.

Assignments are defined in the Denizens node found in plugins/Denizens/config.yml

Denizens:                         
  'Steve':                        
    Scripts:                      
      - 10 Daytime in the City  
    No Scripts To Trigger:
      - CHAT I have nothing to say to you at this time.

Another literal translation. This assignement will work for Denizens named 'Steve'. Triggers that involve this NPC, such as a 'Click Trigger' will call the script named 'Daytime in the City'. The 10 before the name is the script priority, useful when assigning multiple scripts, but we'll get into that later. If no scripts meet requirements (in this case -- if it's NOT daytime when clicking on Steve), 'No Scripts To Trigger' will run instead. So to reiterate, if the player clicks on Steve during the daytime, the player will get a chat containing 'Welcome to the city! Isn't it beautiful in the daytime?' If the player clicks during the nighttime, since the script requirements are not met, the player will see a chat containing 'I have nothing to say to you at this time.'

Multiple Scripts

The key to Denizens being dynamic is their ability to handle multiple situations. This is done by multiple script assignments. Let's take this example config.yml below to see how script priority is handled.

Denizens:                         
  'Steve':                        
    Scripts:                      
      - 0 Regular Joe
      - 10 Joe the Builder  

Scripts: 
  'Regular Joe':   
    Requirements:
      Mode: None
    Steps:
      0:
        Click Trigger:
          - CHAT Hello <PLAYER>! I supply builders only!

  'Joe the Builder':   
    Requirements:
      Mode: All
    List:
      - PERMISSION modifyworld.*
    Steps:
      0:
        Click Trigger:
          - CHAT Hello <PLAYER> the Builder! Take this shovel!
          - GIVE WOOD_SPADE 1

Denizen Steve has been assigned two scripts. Upon player interaction, each script is checked for met requirements. If only one script has their requirements met, it's clear what script will be returned. But what if both meet requirements? That's where the number before each script assigned comes in. Higher priority always wins. To break down this specific situation, if a player with the modifyworld.* permission clicks on Steve, both scripts meet the requirements, but since the script 'Joe the Builder' has a priority of 10, and 'Regular Joe' only has a priority of 0, 'Joe the Builder' sends its script. 'Regular Joe' is simply ignored. Denizens can be issued as many scripts as you want. If two scripts have the same priority, the first in the list will be the one to trigger, if both scripts meet their requirements.

Some other basic things to note

Denizens with the same name use the same script assignments. The plus to this is the ability to quickly make 'generic NPCs' such as a 'Townsman' or 'Miner'.

In the YAML files, nodes are case sensitive! 'Scripts:' will work. 'scripts:' will not! All nodes are first letter capital, rest of the word lowercase.

Scripts in detail

The general structure of a script should always include the 'Name', 'Requirements', and 'Steps' nodes. These are required. You can optionally include 'Options', which include other conditions, such as if the script should have a cool-down or is not repeatable.

Scripts are defined in the plugins/Denizen/config.yml under the Scripts: node.

Remember! Spacing is CRITICAL when dealing with YAML files. Each parent node and sibling node should follow the spacing and formatting guidelines set forth by the YAML 1.0 standard.

From the official 1.0 YAML Specs, this is section 4.2.1 on Indentation:

YAML streams use lines and spaces to convey structure. This requires special processing rules for white space (space and tab).

In a YAML character stream, structure is often determined from indentation, where indentation is defined as a line break character followed by zero or more space characters. With one notable exception, a node must be more indented than its parent node. All sibling nodes must use the exact same indentation level, however the content of each such node could be further indented. Indentation is used exclusively to delineate structure and is otherwise ignored; in particular, indentation characters must never be considered part of the document's content.

Tab characters are not allowed in indentation since different systems treat tabs differently. To maintain portability, YAML's tab policy is conservative; they shall not be used. Note that most modern editors may be configured so that pressing the tab key results in the insertion of an appropriate number of spaces. 

In all the examples used in this guide, 2 spaces are used for indenting. Generally, whatever you choose should be maintained through your YAML document.

General layout of a Script

Scripts:              # Scripts Node
  'Name of script':   # Name Node
    Requirements:     # Requirements Node
      ...:
      ...:
        - ...
        - ...
    Steps:            # Steps Node
      ...:
        - ...
      ...:
    Options:          # Options Node
      ...:

Name Node

This node is pretty self-explanatory, but here are some things to keep in mind.

• Names, just like nodes are case-sensitive! 'This script name' is different than 'THIS SCRIPT NAME'.
• Names that contain spaces must have single or double quotes around it. ie: "This script": or 'This script': is acceptable.
• If the name includes a single quote in it, you must use double quotes around it, or 'escape' the quote with another quote. ie: "John's Script": or 'Johns Script':

Requirements Node

This node sets the rules for the player to qualify for the quest. There are a couple different options that you should know when using requirements. For example:

  Requirements:
    Mode: All
  List:
    - TIME Night
    - MONEY 1000000
    - STORMY

This would be a difficult script to obtain, for sure. To trigger, the time would have to be after 16000, but before 0, the player would need one million dollars on hand (or whatever economy you use), and the weather must be storming! But it shows the flexibility of requirements. First is the 'Mode'. Currently there are three different types. Second is the requirement type, with arguments if applicable.

Mode Types

[] indicates required field

• All - Requires all permissions to be met.
• Any [#] - Requires the specified number of requirements to be met, out of the total of requirements listed.
• None - Requires NO permissions to be met.

Requirements Types

[] indicates required field, () indicates an optional field, OR indicates alternative usage.

NAME, WEARING, INVINSIBLE, ITEM, HOLDING, TIME, PRECIPITATION,

       STORMY, SUNNY, HUNGER, WORLD, PERMISSION, LEVEL, SCRIPT, NOTABLE, GROUP, MONEY, POTIONEFFECT

• Name [Player Name]
• Wearing [ITEM_NAME]

  Test