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 Issues page for Denizens. You can also get assistance with Denizens on the 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 requirements listed to be met.

• ANY [#]

  Requires the specified number of requirements to be met, out of the total of requirements listed.

• NONE

  Requires NO requirements to be met.

Requirements Types

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

• NAME [Player Name] (or this Player Name) (or this Player Name..) (Etc..)

  Requires a specific player.

• WEARING [ITEM_NAME] (ENCHANTMENT_TYPE)

  Requires the player to be wearing a specific piece of armor.

• INVINCIBLE

  Requires the player to be under the effect of a golden apple.

• ITEM [ITEM_NAME] (# of that item, or more) (ENCHANTMENT_TYPE)

  Requires the player to have an item in their inventory. You can also specify an amount and enchantment.

• HOLDING [ITEM_NAME] (# of that item, or more) (ENCHANTMENT_TYPE)

  Requires the player to have an item in their hand. You can also specify an amount and enchantment.

• TIME [Day|Night] OR Time [0-23999] [1-24000]

  Requires day or night. Alternatively you can specify a time window.

• PRECIPITATION

  Requires rain or snow.

• STORMY

  Requires a storm. Note: This is not the same as raining, though it does rain while storming.

• SUNNY

  Requires no precipitation. Note: This does not check time, so it technically could be night and still trigger.

• HUNGER FULL OR HUNGER HUNGRY OR HUNGER STARVING

  Requires a specific hunger state.

• WORLD [World Name] (or this World Name) (or this World Name..) (Etc..)

  Requires the player to be in a specific world, or worlds. You can check as many as you'd like with one line.

• PERMISSION [this.permission.node] (or.this.permission.node..) (Etc..)

  Requires one of the listed permission nodes. Only one is required. If you require multiple permission nodes, use multiple entries.

• LEVEL [This Level # or higher] OR LEVEL [At least this Level #] [But no more than this Level #]

  Requires a specific Minecraft level, or a range of levels.

• SCRIPT [Script Name] (Number of times completed, or more)

  Requires a specific script to be FINISHed, x amount of times or more. If no number is provided, 1 time is assumed.

• NOTABLE [Name of Notable] (or this Notable) (or this Notable..) (Etc..)

  Requires a Notable to be achieved by the player. See: Notables in Denizens

• GROUP [Name of Group] (or this Group) (or this Group..) (Etc..)

  Requires the player be a member of a group. Requires a Permissions system that allows groups, such as PermissionsEX.

• MONEY [Amount of Money, or more]

  Requires the player to have at least a certain amount of money on hand. Requires an economy system, such as iConomy.

• POTIONEFFECT [POTION_EFFECT] (or this POTION_EFFECT..) (Etc..)

  Requires the player to be under the influence of a specific potion. You can use 'ANY' to specify the player just be under the influence of a potion, without being specific as to which type.