Denizen Script Language Explanations


Language Explanations explain components of Denizen in a more direct and technical way than The Beginner's Guide.


Showing all 56 language explanations...

Categories:

Client Information | Common Terminology | Comparables | Denizen Scripting Language | GUI System | image | Object System | Script Command System | Script Container System | Script Events | Tag System | Useful Lists



Category: Client Information


NameClient-side entity data
DescriptionEntity data controlled by Clientizen can be separated into 2 categories: server data, and Clientizen data.
Server data is anything about an entity that is provided by the server, such as whether a sheep is sheared, the block an enderman is holding, etc.
While controllable client-side, the value on the server doesn't actually change, so any time the entity is reloaded (unloaded and then loaded again),
the client receives the entity's actual data from the server, and any changes made client-side do not persist.

Clientizen data is any data that's added by Clientizen, and thus the server isn't aware of.
This means that the data is only ever present client-side, and while it persists when an entity is reloaded, it will be cleared when the client disconnects/closes.
GroupClient Information
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/util/EntityAttachmentPersister.java#L16

NameKeyboard Keys
DescriptionThe Minecraft client recognizes a specific set of keyboard and mouse keys, as listed below:
Keyboard keys:
Letters: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z
Numbers: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
F(unction) keys: F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F18, F19, F20, F21, F22, F23, F24, F25
Keypad: KEYPAD_0, KEYPAD_1, KEYPAD_2, KEYPAD_3, KEYPAD_4, KEYPAD_5, KEYPAD_6, KEYPAD_7, KEYPAD_8, KEYPAD_9, KEYPAD_DECIMAL,
KEYPAD_DIVIDE, KEYPAD_MULTIPLY, KEYPAD_SUBTRACT, KEYPAD_ADD, KEYPAD_ENTER, KEYPAD_EQUAL
Special characters: APOSTROPHE, COMMA, MINUS, PERIOD, SLASH, SEMICOLON, EQUAL, GRAVE_ACCENT, LEFT_BRACKET, RIGHT_BRACKET, BACKSLASH, SPACE
Shift keys: LEFT_SHIFT, RIGHT_SHIFT
World (globe/FN) keys: WORLD_1, WORLD_2
Arrows: ARROW_RIGHT, ARROW_LEFT, ARROW_DOWN, ARROW_UP
Control keys: LEFT_CONTROL, RIGHT_CONTROL
Alt keys: LEFT_ALT, RIGHT_ALT
Lock keys: CAPS_LOCK, NUM_LOCK, SCROLL_LOCK
Page keys: PAGE_UP, PAGE_DOWN
Super (Windows/system/command) keys: LEFT_SUPER, RIGHT_SUPER
Other keys: ESCAPE, ENTER, TAB, BACKSPACE, INSERT, DELETE, HOME, END, PRINT_SCREEN, PAUSE, MENU

Mouse buttons: MOUSE_LEFT, MOUSE_RIGHT, MOUSE_MIDDLE, MOUSE_BUTTON_4, MOUSE_BUTTON_5, MOUSE_BUTTON_6, MOUSE_BUTTON_7, MOUSE_BUTTON_8

If a key is unrecognized, it will be 'UNKNOWN'.
GroupClient Information
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/events/KeyPressReleaseScriptEvent.java#L249



Category: Common Terminology


NameNumber and Decimal
DescriptionMany arguments in Denizen require the use of a 'number', or 'decimal'. Sometimes shorthanded to '#' or '#.#',
this kind of input can generally be filled with any reasonable positive or negative number.
'decimal' inputs allow (but don't require) a decimal point in the number.
'number' inputs will be rounded, so avoiding a decimal point is better. For example, '3.1' will be interpreted as just '3'.
GroupCommon Terminology
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/ArgumentHelper.java#L14



Category: Comparables


NameOperator
DescriptionAn operator is a tool for comparing values, used by commands like Command:if, Command:while, Command:waituntil, ... and tags like Tag:ObjectTag.is.than

Available Operators include:
"Equals" is written as "==" or "equals".
"Does not equal" is written as "!=".
"Is more than" is written as ">" or "more".
"Is less than" is written as "<" or "less".
"Is more than or equal to" is written as ">=" or "or_more".
"Is less than or equal to" is written as "<=" or "or_less".
"does this list or map contain" is written as "contains". For example, "- if a|b|c contains b:" or "- if [a=1;b=2] contains b:"
"is this in the list or map" is written as "in". For example, "- if b in a|b|c:", or "- if [a=1;b=2] contains b:"
"does this object or text match an advanced matcher" is written as "matches". For example, "- if <player.location.below> matches stone:"

Note: When using an operator in a tag,
keep in mind that < and >, and even >= and <= must be either escaped, or referred to by name.
Example: "<player.health.is[<&lt>].than[10]>" or "<player.health.is[less].than[10]>",
but <player.health.is[<].than[10]> will produce undesired results. <>'s must be escaped or replaced since
they are normally notation for a replaceable tag. Escaping is not necessary when the argument
contains no replaceable tags.

There are also special boolean operators (&&, ||, ...) documented at: Command:if
GroupComparables
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/Comparable.java#L14



Category: Denizen Scripting Language


NamedScript
DescriptionThe overall 'scripting language' that Denizen implements is referred to as 'dScripting', or 'dScript'.
dScripts use the Denizen script syntax and the Denizen Scripting API to parse scripts that are stored as .dsc files.
Scripts go in the 'plugins/Denizen/scripts' folder.
GroupDenizen Scripting Language
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L44

NameFlag System
DescriptionThe flag system is a core feature of Denizen, that allows for persistent data storage linked to objects.

"Persistent" means the data is still around even after a server restart or anything else, and is only removed when you choose for it to be removed.
"Linked to objects" means rather than purely global values, flags are associated with a player, or an NPC, or a block, or whatever else.

See also the guide page at 🔗https://guide.denizenscript.com/guides/basics/flags.html.

For non-persistent temporary memory, see instead Command:define.
For more generic memory options, see Command:yaml or Command:sql.

Flags can be sub-mapped with the '.' character, meaning a flag named 'x.y.z' is actually a flag 'x' as a MapTag with key 'y' as a MapTag with key 'z' as the final flag value.
In other words, "<server.flag[a.b.c]>" is equivalent to "<server.flag[a].get[b].get[c]>"

Server flags can be set by specifying 'server' as the object, essentially a global flag target, that will store data in the file "plugins/Denizen/server_flags.dat"

Most unique object types are flaggable - refer to any given object type's language documentation for details.

Most flag sets are handled by Command:flag, however items are primarily flagged via Command:inventory with the 'flag' argument.
Any supported object type, including the 'server' base tag, can use the tags
Tag:FlaggableObject.flag, Tag:FlaggableObject.has_flag, Tag:FlaggableObject.flag_expiration, Tag:FlaggableObject.list_flags.

Additionally, flags be searched for with tags like Tag:server.online_players_flagged, Tag:server.players_flagged, Tag:server.spawned_npcs_flagged, Tag:server.npcs_flagged, ...
Flags can also be required by script event lines, as explained at Language:Script Event Switches.
Item flags can also be used as a requirement in Command:take.

Note that some internal flags exist, and are prefixed with '__' to avoid conflict with normal user flags.
This includes:
- '__raw' and '__clear' which are part of a fake-flag system used for forcibly setting raw data to a flaggable object,
- '__scripts', '__time', etc. which is where some object-type flags are stored inside of server flags,
- '__interact_step' which is used for interact script steps, related to Command:zap,
- '__interact_cooldown' which is used for interact script cooldowns, related to Command:cooldown.

Flags have an expiration system, which is used by specifying a time at which they should expire (or via a duration which internally calculates the date/time of expiration by adding the duration input to the current date/time).
Expirations are then *checked for* in flag tags - meaning, the flag tags will internally compare a stored date/time against the real current date/time,
and if the flag's expiration time is in the past, the flag tag will return values equivalent to if the flag doesn't exist.
There is no system actively monitoring for flag expirations or applying them. There is no event for expirations occurring, as they don't "occur" per se.
In other words, it is correct to say a flag "is expired" or a flag "is not expired",
but it is incorrect to say a flag "expires", as it is not an active action (though this wording can be convenient when speaking informally).
Expired flags are sometimes 'cleaned up' (meaning, any expired flags get actually removed from internal storage), usually when a flag save file is loaded into the server.

As a bonus feature-combo, it is possible to transmit sets of flags exactly in-place and reapply them, this is particular useful for example to synchronize player data across Bungee servers.
To do this, you can read raw flag data with the tag Tag:FlaggableObject.flag_map and the '__raw' prefix in a flag command. For example:

# Gather the original data
- define playerdata <player.flag_map[flag1|flag2|taco|potato|waffle|etc]>
# Now reapply it elsewhere (eg a different Bungee server)
- flag <player> __raw:<[playerdata]>
GroupDenizen Scripting Language
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/core/FlagCommand.java#L34

NameScript
DescriptionA somewhat vague term used to describe a collection of script entries and other script parts.

For example, 'Hey, check out this script I just wrote!', probably refers to a collection of script entries that make up some kind of script container.
Perhaps it is a NPC Assignment Script Container that provides waypoint functionality, or a world script that implements and keeps track of a new player stat.
'Script' can refer to a single container, as well as a collection of containers that share a common theme.

Scripts that contain a collection of containers are typically kept to a single file.
Multiple containers are permitted inside a single file, but it should be noted that container names are stored on a global level.
That is, naming scripts should be done with care to avoid duplicate script names.
GroupDenizen Scripting Language
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L28

NameScript Syntax
DescriptionThe syntax of Denizen is broken into multiple abstraction layers.

At the highest level, Denizen scripts are stored in script files, which use the '.dsc' suffix

Denizen script syntax is approximately based on YAML configuration files,
and is intended to seem generally as easy to edit as a YAML configuration.
However, several key differences exist between the Denizen script syntax and YAML syntax.
In particular, there are several changes made to support looser syntax rules
and avoid some of the issues that would result from writing code directly into a plain YAML file.

Within those 'script files' are 'script containers', which are the actual unit of separating individual 'scripts' apart.
(Whereas putting containers across different files results in no actual difference:
file and folder separation is purely for your own organization, and doesn't matter to the Denizen parser).
Each script container has a 'type' such as 'task' or 'world' that defines how it functions.

Within a script container are individual script paths, such as 'script:' in a 'task' script container,
or 'on player breaks block:' which might be found within the 'events:' section of a 'world' script container.
These paths are the points that might actually be executed at any given time.
When a path is executed, a 'script queue' is formed to process the contents of that script path.

Within any script path is a list of 'script entries', which are the commands to be executed.
These can be raw commands themselves (like 'narrate') with their arguments,
or commands that contain additional commands within their entry (as 'if' and 'foreach' for example both do).
GroupDenizen Scripting Language
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L54



Category: GUI System


NameBar GUI Element
DescriptionProgress bars let you display progress out of a custom max value; they have a UI type of "progress_bar".


ui_type: progress_bar
# The direction the bar moves in as its value increases, required.
direction: UP/RIGHT/DOWN/LEFT
# The texture used for the bar's background, optional.
background: <GUI Texture>
# The texture used for the bar's progress meter, optional.
bar: <GUI Texture>
# The amount of progress the bar made out of its max progress, optional.
value: <number>
# The max value a bar can have, a bar's value is counting up towards this value, optional.
max_value: <number>
# A tooltip to be shown when hovering over the bar.
tooltip: <text>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ProgressBarElement.java#L20

NameBox Panel GUI Element
DescriptionBoxes are a type of panel that that sort the elements they contain evenly along an axis; they have a UI type of "box_panel".


ui_type: box_panel
# The axis to sort the elements in the box panel along, required.
axis: HORIZONTAL/VERTICAL
# The box panel's insets, optional.
insets: <GUI Insets>
# The box panel's background, optional.
background: <GUI Background>
# The spacing between elements in the box panel, optional.
spacing: <number>
# The vertical alignment for elements in the box panel, optional.
vertical_alignment: TOP/CENTER/BOTTOM
# The horizontal alignment for elements in the box panel, optional.
horizontal_alignment: LEFT/CENTER/RIGHT
# The elements in the box panel, optional.
content:
    <key>: <GUI Element>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/BoxPanelElement.java#L22

NameButton GUI Element
DescriptionButtons are clickable GUI elements that can run code when clicked; they have a UI type of "button".
See also Language:Toggle Button GUI Element, for buttons made specifically to control a single boolean value.


ui_type: button
# A label for the button, optional.
label: <text>
# An icon for the button, optional.
icon: <GUI Icon>
# The icon's size (width and height), optional.
icon_size: <number>
# Horizontal text alignment for the button's label, optional.
horizontal_text_alignment: LEFT/CENTER/RIGHT
# Code to run when the button is pressed, optional.
on_click:
- <script>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ButtonElement.java#L26

NameDynamic Label GUI Element
DescriptionDynamic labels work similarly to Language:Label GUI Elements, but with dynamically updating text; they have a UI type of "dynamic_label".


ui_type: dynamic_label
# The dynamically updating text for the label, required.
text: <text>
# The vertical alignment for the label's text, optional.
vertical_alignment: TOP/CENTER/BOTTOM
# The horizontal alignment for the label's text, optional.
horizontal_alignment: LEFT/CENTER/RIGHT
# The color for the label's text, optional.
color: <ColorTag>

The text, including tags, is parsed every frame.
With complex/otherwise computationally expensive tags, you should usually prefer using your own system for updating the text,
to avoid performance issues due to rapid parsing of such tags.
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/DynamicLabelElement.java#L21

NameGrid Panel GUI Element
DescriptionGrid panels are a type of panel that aligns the elements it contains along a grid of squares (known as cells); they have a UI type of "grid_panel".
The x/y/width/height of every element within it is in grid cells instead of individual pixels,
which means that, for example, "x: 2" would mean 2 grid cells off.


ui_type: grid_panel
# The size of each cell in the grid, required.
grid_size: <number>
# The grid panel's insets, optional.
insets: <GUI Insets>
# The grid panel's background, optional.
background: <GUI Background>
# The horizontal spacing between grid cells, optional.
horizontal_spacing: <number>
# The vertical spacing between grid cells, optional.
vertical_spacing: <number>
# The GUI elements in the grid panel, optional.
content:
    <key>: <GUI Element>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/GridPanelElement.java#L18

NameGUI Backgrounds
DescriptionBackgrounds can take in a single ObjectType:ColorTag, or a config for a color with a custom contrast between the bright/dark edges:

# The color to use for the background, required.
color: <ColorTag>
# The contrast between the color and the bright/dark edges of the background, required.
contrast: <decimal>

Alternatively, specify a texture path within the GUI sprite texture atlas, e.g. "minecraft:widget/button" for "minecraft/textures/gui/sprites/widget/button.png".
You can also use custom textures added by resource packs, see 🔗https://minecraft.wiki/w/Resource_pack#GUI for more information.
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L449

NameGUI Element
DescriptionA GUI element is a single object in a GUI.
It takes in a required "ui_type" key, which controls its type; see the "GUI System" group on the meta docs for documentation on each type.
It also takes in optional "width" and "height" keys to control it's size, and optional "x" and "y" keys to control its position.
A GUI element's position is the position of its top left corner, relative to the top left corner of its parent element.
"parent element" refers to the GUI element this element is in, for example a button inside a plain panel.
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L85

NameGUI Icons
DescriptionIcons can take in either:
A single ObjectType:ItemTag, to have the icon show an item.
Or a Language:GUI Textures, to have the icon show a specific texture.
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L416

NameGUI Insets
DescriptionGUI elements that contain other elements sometimes allow setting insets.
Insets are a set of distances elements within another element should keep from its edges.
So for example, in a plain panel with an inset of 5 on all directions, all elements within it will automatically be at least 5 away from its edges.

An example of a basic insets config:

# All 4 of these are required, and control the distance from different edges.
top: <number>
left: <number>
bottom: <number>
right: <number>
# Optionally replace all 4 of these with this single key, which sets a single inset for all edges.
all: <number>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L318

NameGUI Textures
DescriptionGUI Textures directly relate to textures loaded in from resource packs (including the built-in one).
They can be a single texture, or a section of a texture from a sprite sheet.
Since these use the resources system, you can also add and use custom textures yourself via custom resource packs.

Textures can either be a single texture path: minecraft:textures/block/cobblestone.png
Or a section of a sprite sheet:

# The sprite sheet to use a part of, required.
texture: <texture path>
# The left value of the top left point of the area to use, required.
u: <decimal>
# The top value of the top left point of the area to use, required.
v: <decimal>
# The width of the area to use, required.
width: <decimal>
# The height of the area to use, required.
height: <decimal>

All of the UV values (including the width and height) are between 0 and 1 and are relative to the entire image.
So for example: 0, 0, 1, 1 (in order) will be the entire image, 0.5, 0.5, 0.5, 0.5 will be the bottom right half, etc.
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L357

NameItem GUI Element
DescriptionItem GUI elements show an item, potentially looping over a list of items and switching between them; they have a UI type of "item".


ui_type: item
# The item (or list of items) to display, required.
items: <ListTag(ItemTag)>
# The duration to show each item for when more than one is specified, optional.
frame_duration: <DurationTag>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ItemElement.java#L19

NameLabel GUI Element
DescriptionLabels are simple, single lines of text; they have a UI type of "label".
See Language:Text GUI Elements for multi-line text,
and Language:Dynamic Label GUI Element for dynamically updating labels.


ui_type: label
# The text the label will show, optional.
text: <text>
# The vertical alignment for the label's text, optional.
vertical_alignment: TOP/CENTER/BOTTOM
# The horizontal alignment for the label's text, optional.
horizontal_alignment: LEFT/CENTER/RIGHT
# The label's text color, optional.
color: <ColorTag>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/LabelElement.java#L20

NameLabeled Slider GUI Element
DescriptionLabeled sliders work similarly to Language:Slider GUI Elements, but have a label and a different design; they have a UI type of "labeled_slider".

Labeled sliders have all the same keys and values as normal Language:Slider GUI Elements, and additionally:

ui_type: labeled_slider
# A static unchanging label for the slider, optional.
label: <text>
# A dynamic label for the slider that updates every time the slider's value changes, optional.
# Provides <context.value>, returns an ElementTag(Number) of the slider value the label is being parsed for.
# Note that this overrides the normal label if specified.
dynamic_label: <text>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/LabeledSliderElement.java#L22

NamePlain Panel GUI Element
DescriptionPlain panels are the most basic type of panels, allowing their contained elements full control; they have a UI type of "plain_panel".
Unlike other panel types, plain panels do not organize their contained elements in any way,
giving them complete freedom to directly set their position/location.


ui_type: plain_panel
# The plain panel's insets, optional.
insets: <GUI Insets>
# The plain panel's background, optional.
background: <GUI Background>
# The plain panel's contained elements, optional.
content:
    <key>: <GUI Element>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/PlainPanelElement.java#L16

NameScroll Panel GUI Element
DescriptionScroll panels are a type of panel that lets you scroll through its content; they have a UI type of "scroll_panel".


# The scroll panel's contained GUI element, required.
content: <GUI Element>
# The scroll panel's insets, optional.
insets: <GUI Insets>
# The scroll panel's background, optional.
background: <GUI Background>
# Whether the scroll panel should have a vertical scroll bar, optional (defaults to DEFAULT).
vertical_scroll: FALSE/DEFAULT (automatically add/remove based on the content's size)/TRUE
# Whether the scroll panel should have a horizontal scroll bar, optional (defaults to DEFAULT).
horizontal_scroll: FALSE/DEFAULT (automatically add/remove based on the content's size)/TRUE
# The scroll panel's vertical scroll speed, optional.
vertical_scroll_speed: <number>
# The scroll panel's horizontal scroll speed, optional.
horizontal_scroll_speed: <number>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ScrollPanelElement.java#L18

NameSlider GUI Element
DescriptionSliders allow controlling a number (integer) value, with a customizable min/max values; they have a UI type of "slider".


ui_type: slider
# The minimum value the slider can hold, optional (defaults to 0).
min: <number>
# The maximum value the slider can hold, required.
max: <number>
# The axis the slider slides along, required.
axis: HORIZONTAL/VERTICAL
# The direction the slider slides in along its axis to increase its value, optional.
# Defaults to UP for vertical sliders, and RIGHT for horizontal sliders.
# Note that the direction must match the axis, UP/DOWN for VERTICAL, and LEFT/RIGHT for HORIZONTAL.
direction: UP/DOWN/LEFT/RIGHT
# The value the slider should be on, optional.
value: <number>
# Code to run when the slider's value is changed in the slightest (each number it goes through while dragging), optional.
# Provides <context.new_value>, returning an ElementTag(Number) of the slider's new value.
# Should generally prefer listening to the final value set instead of this.
on_change:
- <script>
# Code to run when the slider's value is set (the user finished changing it), optional.
# Provides <context.new_value>, returning an ElementTag(Number) of the slider's new value.
on_set:
- <script>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/SliderElement.java#L30

NameSprite GUI Element
DescriptionSprites display a Language:GUI Textures, optionally taking a list and cycling between them; they have a UI type of "sprite".


ui_type: sprite
# A single texture to display, optional (must specify either this or a list of frames).
texture: <GUI Texture>
# A list of frames to display, optional (must specify either this or a single texture).
frames:
    <key>: <GUI Texture>
# The duration to display each frame for, required when specifying frames.
frame_duration: <DurationTag>
# A tint to apply onto each texture shown by the sprite element, optional.
tint: <ColorTag>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/SpriteElement.java#L22

NameTab Panel GUI Element
DescriptionTab panels are a type of panel that contains several elements, each under its own tab; they have a UI type of "tab_panel".


ui_type: tab_panel
# The tab panel's background, optional.
background: <GUI Background>
# The tab panel's tabs, optional.
tabs:
    <tab id>:
        # A tab's content, required.
        content: <GUI Element>
        # A tab's title, optional.
        title: <text>
        # A tab's tooltip (shown when hovering over it), optional.
        tooltip: <ListTag>
        # A tab's icon, optional.
        icon: <GUI Icon>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/TabPanelElement.java#L23

NameText Field GUI Element
DescriptionText fields allow taking text input from a user; they have a UI type of "text_field".


ui_type: text_field
# Suggestion text to display in the text field until actual text is inputted, optional.
suggestion: <text>
# Pre-existing input text to set into the text field, optional.
text: <text>
# Whether the text field is editable, optional.
editable: <boolean>
# The maximum amount of characters a text field can hold, optional (defaults to 16).
max_length: <number>
# The color a text field's text should have when not editable, optional.
disabled_color: <ColorTag>
# The color a text field's text should have when editable, optional.
enabled_color: <ColorTag>
# The color a text field's suggestion text should have, optional.
suggestion_color: <ColorTag>
# A tag that determines whether an input is valid, blocking it otherwise. optional.
# Provides <context.new_text>, returning an ElementTag of the text field's text, as it would be with the new input.
input_checker: <tag, returning a boolean>
# Code to run when the text field's text is changed, optional.
# Provides <context.new_text>, returning an ElementTag of the text field's new text.
on_change:
- <script>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/TextFieldElement.java#L32

NameText GUI Element
DescriptionText GUI elements display (potentially multi-line) text; they have a UI type of "text".
See also Language:Label GUI Element.


ui_type: text
# The text element's text, required.
text: <text>
# The text element's text color, optional.
color: <ColorTag>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/TextElement.java#L17

NameToggle Button GUI Element
DescriptionToggle buttons control a single boolean value, toggling it when pressed; they have a UI type of "toggle_button".
See also Language:Button GUI Element for normal buttons.


ui_type: toggle_button
# The toggle button's label, optional.
label: <text>
# The texture to display when the toggle button is set to "true", optional.
on_texture: <GUI Texture>
# The texture to display when the toggle button is set to "false", optional.
off_texture: <GUI Texture>
# The texture to display when the toggle button is focused, optional.
focused_texture: <GUI Texture>
# The state the toggle button should be set to, optional (defaults to false).
state: <boolean>
# Code to run when the toggle button is toggled, optional.
# Provides <context.new_value>, returning an ElementTag(Boolean) of the toggle button's new value.
on_toggle:
- <script>
GroupGUI System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ToggleButtonElement.java#L27



Category: image


NameImage positions
DescriptionSome image-related features take in x and y values, which represent a point on the image.
The values are relative to the upper left corner of the image, which acts as 0,0.
If the values are meant to represent the position of a larger object (a shape, an image being drawn onto another image, etc.),
they represent the position of that object's upper left corner.
Groupimage
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/core/DrawCommand.java#L57



Category: Object System


NameAdvanced Object Matching
DescriptionScript event lines often include specific 'matchable' keywords.
For example, while you can write "on player breaks block:" as a script event line,
you can also instead write "on player breaks stone:" to listen to a much more specific event.
This is general in-line matching.
This is made available to avoid needing to do things like "- if <context.material.name> == stone"
just to validate whether an event is even relevant to you.

Of course, there are times when you want to more than one specific thing to be handled by the event, so what do you do?
The Denizen script event system provides a few 'advanced' options to get more detailed matching.

One option is to use wildcards.
For example, there are several 'log' materials, such as 'oak_log', 'birch_log', and more for the rest of the tree types.
So how can you match a player breaking any of these? Use "on player breaks *_log:"
The asterisk is a generic wildcard, it means any text at all will match. So an asterisk followed by '_log' means
any material at all that has a name ending with '_log', including 'birch_log' and the rest.

Note that you can also use multiple wildcards at once, like "on player breaks block with:my_*_script_*:"
That example will work for item scripts named "my_item_script_1" and "my_first_script_of_items" or any similar name.
Note also that wildcards still match for blanks, so "my_item_script_" would still work for that example.

You can also specify lists. For example, if you want an event to work with certain tool types,
the 'on player breaks block:' event supports a switch named 'with', like 'on player breaks block with:iron_pickaxe:'
So lets match multiple tools for our event...
'on player breaks block with:iron_pickaxe|gold_pickaxe|diamond_axe|wooden_shovel:'

You can also combine wildcards and lists... note that lists are the 'wider' option.
That is, if you have wildcards and lists together, you will have a list of possible matches, where each entry may contain wildcards, you will not have a wildcard match with a list.
As a specific example,
'*_pickaxe|*_axe' will match any pickaxe or any axe.
'*_pickaxe|stone' will match any pickaxe or specifically stone. It will NOT match other types of stone, as it interprets
the match to be a list of "*_pickaxe" and "stone", NOT "*" followed by a list of "pickaxe" or "stone".

Additionally, when you're really desperate for a good matcher, you may use 'regex:'
For example, "on player breaks regex:(?i)\d+_customitem:"
Note that generally regex should be avoided whenever you can, as it's inherently hard to track exactly what it's doing at-a-glance, and may have unexpected edge case errors.

If you want to match anything *except* a specific value, just prefix the matcher with '!'
For example, on player breaks !stone:" will fire for a player breaking any block type OTHER THAN stone.
This can be combined with other match modes, like "on player breaks !*wood|*planks|*log:" will fire for any block break other than any wood variant.

Object types have their own special supported matchable inputs, refer to Language:Advanced Object Matchables.

These advanced matchers are also used in some commands and tags, such as Tag:ObjectTag.advanced_matches, or in Command:if with the 'matches' operator.
GroupObject System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L900

NameElementTag(Boolean)
DescriptionWhen "ElementTag(Boolean)" appears in meta documentation, this means the input/output is an ElementTag
(refer to ObjectType:ElementTag) that is a boolean.
Boolean means either a "true" or a "false".
GroupObject System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L67

NameElementTag(Decimal)
DescriptionWhen "ElementTag(Decimal)" appears in meta documentation, this means the input/output is an ElementTag
(refer to ObjectType:ElementTag) that is a decimal number.
That is, for example: 0, 1, 5, -4, 10002325, 4.2, -18.281241 or any other number.
While this is specifically for decimal numbers, the decimal itself is optional (will be assumed as ".0").

In some cases, this will also be documented as "<#.#>".
GroupObject System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L88

NameElementTag(Number)
DescriptionWhen "ElementTag(Number)" appears in meta documentation, this means the input/output is an ElementTag
(refer to ObjectType:ElementTag) that is an integer number.
That is, for example: 0, 1, 5, -4, 10002325 or any other number.
This does NOT include decimal numbers (like 1.5). Those will be documented as Language:ElementTag(Decimal).

In some cases, this will also be documented as "<#>".
GroupObject System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L76

NameUnique Objects vs Generic Objects
DescriptionThere are a lot of object types in the Denizen object system, and not all of them behave the same way.
It can be useful to separate object types into categories to better understand how objects work, and how Denizen as a whole works.
While there are some hardlined separations, there are also some generalizations that don't necessarily hold exactly, but are still helpful.
One such generalization is the separation between Unique and Generic object types.

A UNIQUE object is the way you might assume all objects are.
Unique objects most notably include EntityTag objects and the derivative NPCTag / PlayerTag objects.
An entity object identifies in a form like 'e@<uuid>', where '<uuid>' is some unique ID that looks something like 'abc123-4d5e6f'.
This ID is randomly generated by the Minecraft server and is used to identify that one entity in the world separately from any other.
'e@abc123' is not "a creeper" to the engine, it is "that specific creeper over there".
An object that is unique must have some way to specify the exact single instance of it in the world, like the UUID used by entities.

A GENERIC object can be said to be a 'description' of a unique object.
A generic form of an EntityTag might look like 'e@creeper'.
Instead of "that specific creeper over there", it is instead "the concept of a creeper mob".
There is no way for the engine to read only the word 'creeper' and find out which specific creeper in the world it came from...
it could be any of them, there's often hundreds of creepers spawned somewhere in the world at any time.
Objects like items and materials are always generic. There is no unique identifier for any item, there is only the description.
An item usually looks something like 'i@stick'.
ItemTag objects can include more detail, like 'i@stick[lore=hi;display_name=My Stick;enchantments=[sharpness=5]]'...
but this is still just a description, and there could still be many items out there that match this description.

The consequences of this mostly relate to:
- How you adjust an object (eg change the lore of an item, or teleport an entity).
For example: you can't teleport the generic concept of a creeper, but you can certainly teleport a specific single creeper in the world.
- How reliable tags on the object are.
For example: the result of 'ItemTag.lore' on the item 'i@stick[lore=hi]' will always be 'hi' (because ItemTags are generic),
but the result of 'EntityTag.location' on the entity 'e@abc123' will change every tick as the entity moves,
or even become invalid if the entity dies (because that EntityTag is unique).

Here's where the separation gets muddy:
First, as mentioned, an EntityTag can either be unique ('e@abc123', 'n@42', etc.) OR generic ('e@creeper', 'e@zombie[custom_name=Bob]', etc).
Second, some object types exhibit a bit of both.

For example, a LocationTag refers to a unique block in the world (like, 'l@1,2,3,world' is always that specific block at that position),
but also is a generic object in terms of the location object itself - if for example you want to change the angle of a location,
you have to essentially 'create' a new location, that is an exact copy of the previous one but with a new yaw or pitch value.
GroupObject System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/ObjectTag.java#L43



Category: Script Command System


Name~Waitable
DescriptionA command that is "~Waitable" (or "Holdable", or that can be "~waited for") is a command that:
- Might potentially take a while to execute
- Is able to perform a slowed execution (that doesn't freeze the server)
- And so supports the "~" prefix.

This is written, for example, like: - ~run MySlowScript

When a command is ~waited for, the queue it's in will wait for it to complete, but the rest of the server will continue running.
This is of course similar to the "wait" command, but waits for the action to complete instead of simply for a period of time.

Some commands, particularly those related to file operation, when ~waited for will move the file operation off-thread.
Others may need to be on the server thread, and may split the operation into smaller segments spread out over 1 tick each or similar logic.
Some of these commands, when NOT waited for, will freeze the server thread until the operation completes.
Others, however, may still perform the action in a delayed/slow/off-thread manner, but simply not hold the queue.
GroupScript Command System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/Holdable.java#L9

NameCommand Syntax
DescriptionAlmost every Denizen command and requirement has arguments after the command itself.
These arguments are just snippets of text showing what exactly the command should do,
like what the chat command should say, or where the look command should point.
But how do you know what to put in the arguments?

You merely need to look at the command's usage/syntax info.
Let's take for example:

- animatechest [<location>] ({open}/close) (sound:{true}/false)

Obviously, the command is 'animatechest'... but what does the rest of it mean?

Anything in [brackets] is required... you MUST put it there.
Anything in (parenthesis) is optional... you only need to put it there if you want to.
Anything in {braces} is default... the command will just assume this if no argument is actually typed.
Anything in <> is non-literal... you must change what is inside of it.
Anything outside of <> is literal... you must put it exactly as-is.
<#> represents a number without a decimal, and <#.#> represents a number with a decimal
Lastly, input that ends with "|..." (EG, [<entity>|...] ) can take a list of the input indicated before it (In that example, a list of entities)
An argument that contains a ":" (like "duration:<value>") is a prefix:value pair. The prefix is usually literal and the value dynamic. The prefix and the colon should be kept directly in the final command.

A few examples:
[<location>] is required and non-literal... you might fill it with a noted location, or a tag that returns one like '<player.location>'.
(sound:{true}/false) is optional and has a default value of true... you can put sound:false to prevent sound, or leave it blank to allow sound.
(repeats:<#>) is optional, has no clear default, and is a number. You can put repeats:3 to repeat three times, or leave it blank to not repeat.
Note: Optional arguments without a default usually have a secret default... EG, the (repeats:<#>) above has a secret default of '0'.

Also, you should never directly type in [], (), {}, or <> even though they are in the syntax info.
The only exception is in a replaceable tag (EG: <npc.has_trait[<traitname>]> will take <npc.has_trait[mytrait]> as a valid actual usage)

Highly specific note: <commands> means a block of commands wrapped in braces or as a sub-block... EG:

- repeat 3:
  - narrate "<[value]>"
  - narrate "everything spaced out as a sub-block (these two narrates) following a ":" ended command (that repeat) is for the <commands> input!"
GroupScript Command System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandRegistry.java#L45

NameThe Global If Argument
DescriptionThe "if:<boolean>" argument is a special meta-argument that is available for all commands, but is more useful for some than others.
It is written like:

- stop if:<player.has_flag[forbidden]>
# Equivalent to
- if <player.has_flag[forbidden]>:
  - stop


When the if argument is used, the command will only run if the value of the argument is 'true'.

The most useful place to have this is a 'stop' command, to quickly stop a script if a condition is true (a player has a flag, lacks a permission, is outside a region, or whatever else).

If you need more complex matching, especially using '&&', '||', '==', etc. you should probably just do an 'if' command rather than using the argument.
Though if you really want to, you can use tags here like Tag:objecttag.is.to or Tag:elementtag.and or Tag:elementtag.or.
GroupScript Command System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandExecutor.java#L50

NameThe Save Argument
DescriptionThe "save:<name>" argument is a special meta-argument that is available for all commands, but is only useful for some.
It is written like:
- run MyScript save:mysave

When the save argument is used, the results of the command will be saved on the queue, for later usage by the "entry" tag.

The useful entry keys available for any command are listed in the "Tags" documentation section for any command.
For example, the "run" command lists "<entry[saveName].created_queue>".
The "saveName" part should be replaced with whatever name you gave to the "save" argument,
and the "created_queue" part changes between commands.
Some commands have multiple save entry keys, some have just one, most don't have any.

Many users make the mistake of using dynamic save names like "save:<[something]>" - this is almost always wrong. Use a constant name, just like you do for definitions.
GroupScript Command System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandExecutor.java#L31



Category: Script Container System


NameCustom Script Containers
DescriptionCustom script containers are used to define a template type for a custom object.

Usage of these should generally be avoided, as they can be considered 'over-engineering'...
That is, using a very complicated solution to solve a problem that can be solved much more simply.

Custom objects exist for experimental reasons. Use at your own risk.

Custom script containers have no required keys but several optional ones.
Use 'tags' key to define scripted tags,
'mechanisms' to define scripted mechanisms,
'inherit' to define what other custom script to inherit from,
and any other key name to define a default object field.


Custom_Script_Name:

    type: custom

    # Use 'inherit' to make this custom script container inherit from another custom object.
    inherit: some_object

    # This adds default field 'some_field' with initial value of 'some_value'.
    some_field: some_value

    # List additional fields here...

    # Use 'tags' to define scripted tags on the object.
    # Tags are subject to the same rules as procedure scripts:
    # NEVER change any external state. Just determine a value. Nothing else should change from the script.
    tags:

        # This would be read like <[my_object].my_tag>
        my_tag:
        # Perform any logic here, and 'determine' the result.
        - determine 3

        # list additional tags here...

    # Use 'mechanisms' to define scripted mechanisms on the object.
    # Note that these should only ever determine a new object,
    # with NO CHANGES AT ALL outside the replacement determined object.
    # (Same rules as tags and procedure scripts).
    mechanisms:

        # This would be used like custom@Custom_Script_Name[my_mech=3]
        my_mech:
        - adjust <context.this> true_value:<context.value.mul[2]> save:new_val
        - determine <entry[new_val].result>

        # list additional mechanisms here...

GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/CustomScriptContainer.java#L25

NameData Script Containers
DescriptionData script containers are generic script containers for information that will be referenced by other scripts.

No part of a 'data' script container is ever run as commands.

There are no required keys.

Generally, data is read using the Tag:ScriptTag.data_key tag.


data_script_name:

    type: data

    # Your data here
    some_key: some value
    some_list_key:
    - some list value
    some_map_key:
        some_subkey: some value

GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/DataScriptContainer.java#L9

NameGUI Script Containers
DescriptionGUI script containers represent a UI element (such as a button, scroll panel, etc.).
They contain a Language:GUI Element, and can be opened using Command:Gui.


# An example of a basic GUI script container, with a plain panel as its element.
my_gui:
    type: gui
    ui_type: plain_panel
    width: 200
    height: 200
    content: <GUI Element>
GroupScript Container System
Sourcehttps://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L36

NameProcedure Script Containers
DescriptionProcedure script containers are used to define a script that can be ran through a tag.

Generally called via Tag:proc or Tag:proc.context.

The only required key is 'script:'.

Note that procedure scripts must NEVER change external state.
That is, a procedure script cannot change anything at all, ONLY determine a value.
Setting a flag, loading a YAML document, placing a block, etc. are all examples of external changes that are NOT allowed.

This restriction comes from two main reasons:
- Tags run in arbitrary conditions. They may be read asynchronously or in other weird circumstances that can result
in applied changes crashing your server or other unexpected side effects.
- Tags can run for a variety of reasons.
If you were to make a proc script 'spawn_entity' that actually spawns an entity into the world,
you would likely end up with a *lot* of unintentional entity spawns.
Some tags will be read multiple times when theoretically ran once,
in some circumstances a tag read might even be based on user input! (Particularly if you ever make use of the '.parsed' tag,
or the list.parse/filter/sort_by_number tags).
Imagine if for example, a tag can be read when users input a specific custom command,
and a clever user finds out they can type "/testcommand 32 <proc[spawn_entity].context[creeper]>"
to spawn a creeper ... that would be a major problem!
In general, maximum caution is the best for situations like this... simply *never* make a procedure
that executes external changes.


Proc_Script_Name:

    type: procedure

    # Optionally specify definition names to use with the 'context' input of the proc tag.
    definitions: def|names|here

    script:

    # Put any logic, then determine the result.
    - determine 5

GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/ProcedureScriptContainer.java#L9

NameScript Container
DescriptionScript Containers are the basic structure that Denizen uses inside its YAML-based scripting files found in your
plugins/Denizen/scripts/ folder. Regardless of type, all script containers have basic parts that can usually be
described as keys, list keys, parent keys, child keys, values, and list values. While specific container types
probably have more specific names, just remember that no matter how complicated a script, this basic structure
still applies.

It's important to keep in mind that all child keys, including all the main keys of the script, must line up with
one another, hierarchically. If you are familiar with YAML, great, because all script containers use it at the
core. Every value, in one way or another, belongs to some kind of 'key'. To define a key, use a string value plus
a colon (:). Keys can have a single value, a list value, or own another key:


script name:
    key: value
    list key:
        - list value
        - ...
    parent key:
        child key: value


And here's a container, put into a more familiar context:


a haiku script:
    type: task
    script:
      - narrate "A simple script,"
      - narrate "with a key value relationship."
      - narrate "Oh look, a list!"
GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/ScriptContainer.java#L24

NameScript Name
DescriptionTypically refers to the name of a script container. When using the object fetcher with dScript objects,
(ScriptTag_name), the script_name referred to is the name of the container.


script name:         <--- script name
  type: script_type
  script:            <--- base script
    - script entries
    - ...
  local script:      <--- local script path
    - script entries
    - ...
GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/ScriptContainer.java#L122

NameScript Type
DescriptionThe type of container that a script is in. For example, 'task script' is a script type that has some sort of utility.


script name:
  type: script_type  <--- script type
  script:
    - script entries
    - ...
GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/ScriptContainer.java#L191

NameTask Script Containers
DescriptionTask script containers are generic script containers for commands that can be run at
any time by command.

Generally tasks will be ran by Command:run or Command:inject.

The only required key on a task script container is the 'script:' key.


Task_Script_Name:

    type: task

    # When intending to run a task script via the run command with the "def:" argument to pass data through,
    # use this "definitions" key to specify the names of the definitions (in the same order as the "def:" argument will use).
    # You can optionally document a definition with [square brackets]
    definitions: name1|name2[description here]|...

    script:

    - your commands here

GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/TaskScriptContainer.java#L15

NameWorld Script Containers
DescriptionWorld script containers are generic script containers for commands that are automatically
ran when some given event happens in the server.

The only required key is 'events:', within which you can list any events to handle.

World scripts can be automatically disabled by adding "enabled: false" as a root key (supports any load-time-parseable tags).


World_Script_Name:

    type: world

    events:

        # Any event label can be placed here
        # This includes generic labels like 'on entity death:',
        # Specified labels  like 'on player death:',
        # And detailed labels like 'on player death ignorecancelled:true priority:5:'
        some event label:
        # Write any logic that should fire when the event runs.
        # Optionally 'determine' any results to the event.
        - some commands

        # List additional events here

GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/WorldScriptContainer.java#L9



Category: Script Events


NameScript Event After vs On
DescriptionModern ScriptEvents let you choose between "on" and "after".
An "on" event looks like "on player breaks block:" while an "after" event looks like "after player breaks block:".

An "on" event fires *before* the event actually happens in the world. This means some relevant data won't be updated
(for example, "<context.location.material>" would still show the block type that is going to be broken)
and the result of the event can be changed (eg the event can be cancelled to stop it from actually going through).

An "after" event, as the name implies, fires *after* the event actually happens. This means data will be already updated to the new state
(so "<context.location.material>" would now show air) but could potentially contain an arbitrary new state from unrelated changes
(for example "<context.location.material>" might now show a different block type, or the original one, if the event was changed,
or another thing happened right after the event but before the 'after' event ran).
This also means you cannot affect the outcome of the event at all (you can't cancel it or anything else - the "determine" command does nothing).

See also Language:Safety In Events
GroupScript Events
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L361

NameScript Event Cancellation
DescriptionAny modern ScriptEvent can take a "cancelled:<true/false>" argument and a "ignorecancelled:true" argument.
For example: "on object does something ignorecancelled:true:"
Or, "on object does something cancelled:true:"
If you set 'ignorecancelled:true', the event will fire regardless of whether it was cancelled.
If you set 'cancelled:true', the event will fire /only/ when it was cancelled.
By default, only non-cancelled events will fire. (Effectively acting as if you had set "cancelled:false").

Any modern script event can take the determinations "cancelled" and "cancelled:false".
These determinations will set whether the script event is 'cancelled' in the eyes of following script events,
and, in some cases, can be used to stop the event itself from continuing.
A script event can at any time check the cancellation state of an event by accessing "<context.cancelled>".
GroupScript Events
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L556

NameScript Event Priority
DescriptionAny modern ScriptEvent can take a "priority:#" argument.
For example: "on object does something priority:3:"
The priority indicates which order the events will fire in.
Lower numbers fire earlier. EG, -1 fires before 0 fires before 1.
Any integer number, within reason, is valid. (IE, -1 is fine, 100000 is fine,
but 200000000000 is not, and 1.5 is not as well)
The default priority is 0.
GroupScript Events
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L622

NameScript Event Special Contexts
DescriptionEvery modern ScriptEvent has some special context tags available.
The most noteworthy is "context.cancelled", which tracks whether the script event has been cancelled.
That returns, for example, "on player breaks stone".
The context 'reflect_event' is available in some events (eg Bukkit events) to get a JavaReflectedObjectTag of the raw internal event.
GroupScript Events
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L876

NameScript Event Switches
DescriptionModern script events support the concept of 'switches'.
A switch is a specification of additional requirements in an event line other than what's in the event label it.

A switch consists of a name and a value input, and are can be added anywhere in an event line as "name:<value>".
For example, "on delta time secondly every:5:" is a valid event, where "delta time secondly" is the event itself, and "every:<#>" is a switch available to the event.

A traditional Denizen event might look like "on <entity> damaged",
where "<entity>" can be filled with "entity" or any entity type (like "player").
A switch-using event would instead take the format "on entity damaged" with switch "type:<entity type>"
meaning you can do "on entity damaged" for any entity, or "on entity damaged type:player:" for players specifically.
This is both more efficient to process and more explicit in what's going on, however it is less clear/readable to the average user, so it is not often used.
Some events may have switches for less-often specified data, and use the event line for other options.

There are also some standard switches available to every script event, and some available to an entire category of script events.

One switch available to every event is "server_flagged:<flag_name>", which requires that there be a server flag under the given name.
For example, "on console output server_flagged:recording:" will only run the handler for console output when the "recording" flag is set on the server.
This can also be used to require the server does NOT have a flag with "server_flagged:!<flag_name>"

"chance:<percent>" is also a globally available switch.
For example, "on player breaks diamond_ore chance:25:" will only fire on average one in every four times that a player breaks a diamond ore block.

Events that have a player linked have the "flagged" and "permission" switches available.

If the switch is specified, and an event doesn't have a linked player, the event will automatically fail to match.
The "flagged:<flag_name>" switch will limit the event to only fire when the player has the flag with the specified name.
It can be used like "on player breaks block flagged:nobreak:" (that would be used alongside "- flag player nobreak").
You can also use "flagged:!<flag_name>" to require the player does NOT have the flag, like "on player breaks block flagged:!griefbypass:"

The "permission:<perm key>" will limit the event to only fire when the player has the specified permission key.
It can be used like "on player breaks block permission:denizen.my.perm:"
For multiple flag or permission requirements, just list them separated by '|' pipes, like "flagged:a|b|c". This will require all named flags/permissions to be present, not just one.

Events that have an NPC linked have the "assigned" switch available.
If the switch is specified, and an event doesn't have a linked NPC, the event will automatically fail to match.
The "assigned:<script name>" switch will limit the event to only fire when the NPC has an assignment script that matches the given advanced matcher.

Events that occur at a specific location have the "in:<area>" and "location_flagged" switches.
This switches will be ignored (not counted one way or the other) for events that don't have a known location.
For "in:<area>" switches, 'area' is any area-defining tag type - refer to Language:Advanced Object Matchables.
"location_flagged:<flag name>" works just like "server_flagged" or the player "flagged" switches, but for locations.

All script events have priority switches (see Language:script event priority),
All Bukkit events have bukkit priority switches (see Language:bukkit event priority),
All cancellable script events have cancellation switches (see Language:script event cancellation).

See also Language:Advanced Object Matching.
GroupScript Events
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L236



Category: Tag System


NameTag Fallbacks
DescriptionTag fallbacks (AKA "tag alternatives") are a system designed to allow scripters to automatically handle tag errors.

Fallbacks are implemented as special "magic tags" that look like any other tag-part, but override the error handler. These are "if_null", "exists", and "is_truthy".

A tag without a fallback might look like "<player.name>".
This tag works fine as long as there's a linked player, but what if a player isn't always available?
Normally, this situation would display an error in the console debug logs, and return plaintext "player.name" in the script.
A fallback can help us handle the problem more gracefully.
That same tag with a fallback would look like "<player.name.if_null[Steve]>".
Now, when there isn't a player available, there will not be an error, and the tag will simply return "Steve".

This format is the same for basically all tags. "<main.tag.here.if_null[Fallback here]>".
For another example, "<player.flag[myflag].if_null[0]>" returns either the value of the flag, or "0" if the flag is not present (or if there's no player).

The "exists" fallback-tag is available for checking whether an object exists and is valid.
What if we want to check if there even is a linked player? We don't have a "<has_player>" tag to do that, so what can we do?

- if <player.exists>:

The above example demonstrates using a fallback to check if a player is valid.
The if block will run only if there is not a player valid (you might, for example, place the "stop" command inside).

"Exists" is useful when you *only* need a check, however you often need to grab a value and verify it after.
Consider the following example, often found in command scripts:

- define target <server.match_player[<context.args.get[1]>].if_null[null]>
- if <[target]> == null:
    - narrate "<&[error]>Invalid player!"
    - stop
- narrate "<&[base]>You chose <&[emphasis]><[target].name><&[base]>!"


We use the word "null" in the above example, as well as in the tag name itself. This is a common programming term that means "no object is present".
"if_null" is the actual tag name, however the input value of "null" isn't actually a functionality of Denizen, it's just a word we choose for clarity.
You could just as easily do "- if <player.if_null[nothing]> == nothing:", or for that matter "- if <player.if_null[cheese]> == cheese:".
A player object takes the form "p@uuid", so it will therefore never exactly match any simple word, so there's no coincidental match edge-case to worry about.
Note that this won't work so perfect for things like a user input or fully dynamic value,
so in those cases you may want to use the "exists" tag explicitly to guarantee no potential conflict.

Fallbacks can be tags themselves. So, for example, if we want either a custom flag-based display name, or if not available, the player's base name,
we can do: "<player.flag[display_name].if_null[<player.name>]>".
You can as well chain these: "<player.flag[good_name].if_null[<player.flag[bad_name].if_null[<player.name>]>]>".

Note that fallbacks will *hide errors*. Generally, the only errors you should ever hide are ones you're expecting that are fine.
Don't use a fallback on a "<player.name>" tag, for example, if there should always be a player present when the script runs.
That tag should only ever have a fallback when the script is meant to still work without a player attached.
If you carelessly apply fallbacks to all tags, you might end up not realizing there's a problem in your script until it's affecting real players.
You want to solve errors in testing, not ten months later when a player mentions to you "that shop NPC let me buy things even when I had $0"!

Prior to Denizen 1.2.0, fallbacks exclusively worked with a special "||" syntax, like "- if <player||null> == null:"
This syntax is still fully supported at time of writing, however the newer tag-based format is considered clearer and easier to learn.
GroupTag System
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/Attribute.java#L471



Category: Useful Lists


NameData Actions
DescriptionSeveral commands function as a way to modify data values,
including Command:flag, Command:yaml, and Command:define.
These commands each allow for a set of generic data change operations.

These operations can be used with a syntax like "<key>:<action>:<value>"
For example "mykey:+:5" will add 5 to the value at 'mykey'.

The following actions are available:

Actions that take no input value:
Increment: '++': raises the value numerically up by 1. Example: - define x:++
Decrement: '--': lowers the value numerically down by 1. Example: - define x:--
Remove: '!': removes the value entirely. Example: - define x:!

Actions that take an input value:
Add: '+': adds the input value to the value at the key. Example: - define x:+:5
Subtract: '-': subtracts the input value from the value at the key. Example: - define x:-:5
Multiply: '*': multiplies the value at the key by the input value. Example: - define x:*:5
Divide: '/': divides the value at the key by the input value. Example: - define x:/:5
List insert: '->': adds the input value as a single new entry in the list (see also 'List split'). Example: - define x:->:new_value
List remove: '<-': removes the input value from the list. Example: - define x:<-:old_value
List split: '|': splits the input list and adds each value into an existing list at the key. Example: - define x:|:a|b|c

Special cases:
In some commands, specifying no action or input value will automatically set the key's value to 'true'.
Setting a '<key>:<value>' without an action will set the key to the exact value. Be careful to not input a list like this, use 'split to new' instead.

Note that the <key> input may take an index input as well, for example "mykey[3]:value".
This also works with most actions.
That is, for example: "mykey[3]:--" will decrement the third item in the list at 'mykey'.
This syntax may also be used to remove the entry at a specified index, for example "mykey[3]:<-"
The index can also be "last" to automatically use the last entry in the list as the target.
GroupUseful Lists
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/utilities/data/DataActionType.java#L5

NameEscaping System
DescriptionSometimes, you need to avoid having symbols that might be misinterpreted in your data.
Denizen provides the tags Tag:ElementTag.escaped and Tag:ElementTag.unescaped to help deal with that.
Escaped replaces symbols with the relevant escape-code, and unescaped replaces the escape-codes with the real symbols.

Some older style tags and mechanisms may automatically use this same escaping system.

The mapping of symbols to escape codes is as follows:

(THESE ARE NOT TAG NAMES)

| = &pipe
< = &lt
> = &gt
newline = &nl
& = &amp
; = &sc
[ = &lb
] = &rb
: = &co
at sign @ = &at
. = &dot
\ = &bs
' = &sq
" = &quo
! = &exc
/ = &fs
ยง = &ss
# = &ns
= = &eq
{ = &lc
} = &rc

Also, you can input a non-breaking space via &sp

Note that these are NOT tag names. They are exclusively used by the escaping system.
GroupUseful Lists
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/core/EscapeTagUtil.java#L8