Name | Client-side entity data |
Description | Entity 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. |
Group | Client Information |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/util/EntityAttachmentPersister.java#L16 |
Name | Keyboard Keys |
Description | The 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'. |
Group | Client Information |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/events/KeyPressReleaseScriptEvent.java#L249 |
Name | Number and Decimal |
Description | Many 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'. |
Group | Common Terminology |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/ArgumentHelper.java#L14 |
Name | Operator |
Description | An operator is a tool for comparing values, used by commands like if, while, waituntil, ... and tags like 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[<<>].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: if |
Group | Comparables |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/Comparable.java#L14 |
Name | dScript |
Description | The 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. |
Group | Denizen Scripting Language |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L44 |
Name | Flag System |
Description | The 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 define. For more generic memory options, see yaml or 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 flag, however items are primarily flagged via inventory with the 'flag' argument. Any supported object type, including the 'server' base tag, can use the tags FlaggableObject.flag, FlaggableObject.has_flag, FlaggableObject.flag_expiration, FlaggableObject.list_flags. Additionally, flags be searched for with tags like server.online_players_flagged, server.players_flagged, server.spawned_npcs_flagged, server.npcs_flagged, ... Flags can also be required by script event lines, as explained at Script Event Switches. Item flags can also be used as a requirement in 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 zap, - '__interact_cooldown' which is used for interact script cooldowns, related to 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 FlaggableObject.flag_map and the '__raw' prefix in a flag command. For example:
|
Group | Denizen Scripting Language |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/core/FlagCommand.java#L34 |
Name | Script |
Description | A 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. |
Group | Denizen Scripting Language |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L28 |
Name | Script Syntax |
Description | The 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). |
Group | Denizen Scripting Language |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L54 |
Name | Bar GUI Element |
Description | Progress bars let you display progress out of a custom max value; they have a UI type of "progress_bar".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ProgressBarElement.java#L20 |
Name | Box Panel GUI Element |
Description | Boxes are a type of panel that that sort the elements they contain evenly along an axis; they have a UI type of "box_panel".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/BoxPanelElement.java#L22 |
Name | Button GUI Element |
Description | Buttons are clickable GUI elements that can run code when clicked; they have a UI type of "button".
See also Toggle Button GUI Element, for buttons made specifically to control a single boolean value.
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ButtonElement.java#L26 |
Name | Dynamic Label GUI Element |
Description | Dynamic labels work similarly to Label GUI Elements, but with dynamically updating text; they have a UI type of "dynamic_label".
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. |
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/DynamicLabelElement.java#L21 |
Name | Grid Panel GUI Element |
Description | Grid 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.
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/GridPanelElement.java#L18 |
Name | GUI Backgrounds |
Description | Backgrounds can take in a single ColorTag, or a config for a color with a custom contrast between the bright/dark edges:
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. |
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L449 |
Name | GUI Element |
Description | A 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. |
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L85 |
Name | GUI Icons |
Description | Icons can take in either:
A single ItemTag, to have the icon show an item. Or a GUI Textures, to have the icon show a specific texture. |
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L416 |
Name | GUI Insets |
Description | GUI 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:
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L318 |
Name | GUI Textures |
Description | GUI 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:
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. |
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L357 |
Name | Item GUI Element |
Description | Item GUI elements show an item, potentially looping over a list of items and switching between them; they have a UI type of "item".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ItemElement.java#L19 |
Name | Label GUI Element |
Description | Labels are simple, single lines of text; they have a UI type of "label".
See Text GUI Elements for multi-line text, and Dynamic Label GUI Element for dynamically updating labels.
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/LabelElement.java#L20 |
Name | Labeled Slider GUI Element |
Description | Labeled sliders work similarly to 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 Slider GUI Elements, and additionally:
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/LabeledSliderElement.java#L22 |
Name | Plain Panel GUI Element |
Description | Plain 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.
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/PlainPanelElement.java#L16 |
Name | Scroll Panel GUI Element |
Description | Scroll panels are a type of panel that lets you scroll through its content; they have a UI type of "scroll_panel".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ScrollPanelElement.java#L18 |
Name | Slider GUI Element |
Description | Sliders allow controlling a number (integer) value, with a customizable min/max values; they have a UI type of "slider".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/SliderElement.java#L30 |
Name | Sprite GUI Element |
Description | Sprites display a GUI Textures, optionally taking a list and cycling between them; they have a UI type of "sprite".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/SpriteElement.java#L22 |
Name | Tab Panel GUI Element |
Description | Tab panels are a type of panel that contains several elements, each under its own tab; they have a UI type of "tab_panel".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/TabPanelElement.java#L23 |
Name | Text Field GUI Element |
Description | Text fields allow taking text input from a user; they have a UI type of "text_field".
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/TextFieldElement.java#L32 |
Name | Text GUI Element |
Description | Text GUI elements display (potentially multi-line) text; they have a UI type of "text".
See also Label GUI Element.
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/TextElement.java#L17 |
Name | Toggle Button GUI Element |
Description | Toggle buttons control a single boolean value, toggling it when pressed; they have a UI type of "toggle_button".
See also Button GUI Element for normal buttons.
|
Group | GUI System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/elements/ToggleButtonElement.java#L27 |
Name | Image positions |
Description | Some 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. |
Group | image |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/core/DrawCommand.java#L57 |
Name | Advanced Object Matching |
Description | Script 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 Advanced Object Matchables. These advanced matchers are also used in some commands and tags, such as ObjectTag.advanced_matches, or in if with the 'matches' operator. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L900 |
Name | ElementTag(Boolean) |
Description | When "ElementTag(Boolean)" appears in meta documentation, this means the input/output is an ElementTag
(refer to ElementTag) that is a boolean. Boolean means either a "true" or a "false". |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L67 |
Name | ElementTag(Decimal) |
Description | When "ElementTag(Decimal)" appears in meta documentation, this means the input/output is an ElementTag
(refer to 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 "<#.#>". |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L88 |
Name | ElementTag(Number) |
Description | When "ElementTag(Number)" appears in meta documentation, this means the input/output is an ElementTag
(refer to 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 ElementTag(Decimal). In some cases, this will also be documented as "<#>". |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L76 |
Name | Unique Objects vs Generic Objects |
Description | There 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. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/ObjectTag.java#L43 |
Name | ~Waitable |
Description | A 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. |
Group | Script Command System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/Holdable.java#L9 |
Name | Command Syntax |
Description | Almost 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:
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:
|
Group | Script Command System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandRegistry.java#L45 |
Name | The Global If Argument |
Description | The "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:
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 objecttag.is.to or elementtag.and or elementtag.or. |
Group | Script Command System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandExecutor.java#L50 |
Name | The Save Argument |
Description | The "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. |
Group | Script Command System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandExecutor.java#L31 |
Name | Custom Script Containers |
Description | Custom 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.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/CustomScriptContainer.java#L25 |
Name | Data Script Containers |
Description | Data 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 ScriptTag.data_key tag.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/DataScriptContainer.java#L9 |
Name | GUI Script Containers |
Description | GUI script containers represent a UI element (such as a button, scroll panel, etc.).
They contain a GUI Element, and can be opened using Gui.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Clientizen/blob/master/src/main/java/com/denizenscript/clientizen/scripts/containers/gui/GuiScriptContainer.java#L36 |
Name | Procedure Script Containers |
Description | Procedure script containers are used to define a script that can be ran through a tag.
Generally called via proc or 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.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/ProcedureScriptContainer.java#L9 |
Name | Script Container |
Description | Script 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:
And here's a container, put into a more familiar context:
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/ScriptContainer.java#L24 |
Name | Script Name |
Description | Typically 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.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/ScriptContainer.java#L122 |
Name | Script Type |
Description | The type of container that a script is in. For example, 'task script' is a script type that has some sort of utility.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/ScriptContainer.java#L191 |
Name | Task Script Containers |
Description | Task script containers are generic script containers for commands that can be run at
any time by command. Generally tasks will be ran by run or inject. The only required key on a task script container is the 'script:' key.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/TaskScriptContainer.java#L15 |
Name | World Script Containers |
Description | World 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).
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/WorldScriptContainer.java#L9 |
Name | Script Event After vs On |
Description | Modern 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 Safety In Events |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L361 |
Name | Script Event Cancellation |
Description | Any 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>". |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L556 |
Name | Script Event Priority |
Description | Any 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. |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L622 |
Name | Script Event Special Contexts |
Description | Every 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. |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L876 |
Name | Script Event Switches |
Description | Modern 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 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 script event priority), All Bukkit events have bukkit priority switches (see bukkit event priority), All cancellable script events have cancellation switches (see script event cancellation). See also Advanced Object Matching. |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L236 |
Name | Tag Fallbacks |
Description | Tag 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?
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:
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. |
Group | Tag System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/Attribute.java#L471 |
Name | Data Actions |
Description | Several commands function as a way to modify data values,
including flag, yaml, and 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. |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/utilities/data/DataActionType.java#L5 |
Name | Escaping System |
Description | Sometimes, you need to avoid having symbols that might be misinterpreted in your data.
Denizen provides the tags ElementTag.escaped and 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 < = < > = > newline = &nl & = & ; = &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. |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/core/EscapeTagUtil.java#L8 |