Name | Script Event Object Matchables |
Description | Script events have a variety of matchable object inputs, and the range of inputs they accept may not always be obvious.
For example, an event might be "player clicks <block>"... what can "<block>" be filled with? "<block>" usually indicates that a MaterialTag will be matched against. This means you can specify any valid block material name, like "stone" or "air". You can also use "block" or "material" as catch-alls. "<item>" or similar expects of course an ItemTag. You can use any valid item material type like "stick", or the name of an item script, or "item" as a catch-all, or "potion" for any potion item. Items can also be used with an "item_flagged" secondary prefix, so for an event that has "with:<item>", you can also do "with:item_flagged:<flag name>". For item matchers that aren't switches, this works similarly, like "on player consumes item_flagged:myflag:" (note that this is not a switch). "<entity>", "<projectile>", "<vehicle>", etc. are examples of where an EntityTag will be expected. You can generally specify any potentially relevant entity type, such as "creeper" under "<entity>", or "arrow" for "<projectile>", but you can also specify "entity" (catch-all), "player" (real players, NOT player-type NPCs), "npc" (Citizens NPC), "vehicle" (minecarts, boats, horses, etc), "fish" (cod, pufferfish, etc), "projectile" (arrow, trident, etc), "hanging" (painting, item_frame, etc), "monster" (creepers, zombies, etc), "animals" (pigs, cows, etc), "mob" (creepers, pigs, etc), "living" (players, pigs, creepers, etc), "entity_flagged:<flag_name>", "npc_flagged:<flag_name>", "player_flagged:<flag_name>" (all three work similar to 'item_flagged'). "<inventory>" or similar expects of course an InventoryTag. You can use "inventory" as a catch-all, "note" to mean any noted inventory, the name of an inventory script, the name of an inventory note, the name of an inventory type (like "chest"), or "inventory_flagged:<flag_name>" for noted inventories. "<world>" or similar expects of course a WorldTag. You can use "world" as a catch-all, a world name, or "world_flagged:<flag_name>" (works similar to 'item_flagged'). "<area>" or similar refers to any area-defining tag type, including WorldTag, CuboidTag, EllipsoidTag, and PolygonTag. You can specify the name of any world, the name of any noted area, "world_flagged:<flag_name>", "chunk_flagged:<flag_name>", "area_flagged:<flag_name>" (all work similar to 'item_flagged'), "cuboid" for any noted cuboid, "ellipsoid" for any noted ellipsoid, or "polygon" for any noted polygon. You will also often see match inputs like "<cause>" or "<reason>" or similar, which will expect the name from an enumeration documented elsewhere in the event meta (usually alongside a "<context.cause>" or similar). You can also do more advanced multi-matchers in any of these inputs. For details on that, see Language:Advanced Script Event Matching. |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/events/BukkitScriptEvent.java#L37 |
Name | Bukkit Event Priority |
Description | Script events that are backed by standard Bukkit events are able to control what underlying Bukkit event priority
they register as. This can be useful, for example, if a different plugin is cancelling the event at a later priority, and you're writing a script that needs to un-cancel the event. This can be done using the "bukkit_priority" switch. Valid priorities, in order of execution, are: LOWEST, LOW, NORMAL, HIGH, HIGHEST, MONITOR. Monitor is executed last, and is intended to only be used when reading the results of an event but not changing it. The default priority is "normal". |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/events/BukkitScriptEvent.java#L423 |
Name | Safety In Events |
Description | One of the more common issues in Denizen scripts (particularly ones relating to inventories) is
*event safety*. That is, using commands inside an event that don't get along with the event. The most common example of this is editing a player's inventory, within an inventory-related event. Generally speaking, this problem becomes relevant any time an edit is made to something involved with an event, within the firing of that event. Take the following examples:
In both examples above, something related to the event (the player's inventory, and the entity being damaged) is being modified within the event itself. These break due a rather important reason: The event is firing before and/or during the change to the object. Most events operate this way. A series of changes *to the object* are pending, and will run immediately after your script does... the problems resultant can range from your changes being lost to situational issues (eg an inventory suddenly being emptied entirely) to even server crashes! The second example event also is a good example of another way this can go wrong: Many scripts and plugins will listen to the entity damage event, in ways that are simply unable to handle the damaged entity just being gone now (when the event fires, it's *guaranteed* the entity is still present but that remove command breaks the guarantee!). The solution to this problem is simple: Use "after" instead of "on".
This will delay the script until *after* the event is complete, and thus outside of the problem area. And thus should be fine. One limitation you should note is demonstrated in the second example event: The normal guarantees of the event are no longer present (eg that the entity is still valid) and as such you should validate these expectations remain true after the event (as seen with the 'if is_spawned' check). If you need determine changes to the event, you can instead use 'on' but add a 'wait 1t' after the determine but before other script logic. This allows the risky parts to be after the event and outside the problem area, but still determine changes to the event. Be sure to use 'passively' to allow the script to run in full.
|
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/events/BukkitScriptEvent.java#L796 |
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. Events that have a player linked have the "flagged" and "permission" switches available. Will always fail if the event doesn't have a linked player. The "flagged:<flag name>" 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"). 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:" As with any advanced switch, for multiple flag or permission requirements, just list them separated by '|' pipes, like "flagged:a|b|c". 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:Script Event 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 script event matching. |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L98 |
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). |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L181 |
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#L288 |
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#L328 |
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. You can also use "context.event_header", which returns the exact event header text that fired (which may be useful for some types of dynamic script). That returns, for example, "on player breaks stone". You can also use "context.event_name", which returns the internal name of the script event that fired (which may be useful for some debugging techniques). That returns, for example, "PlayerBreaksBlock". |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L472 |
Name | Advanced Script Event 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|wood_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 do not have a 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. See also Language:script event object matchables. These advanced matchers are also used in some commands and tags. |
Group | Script Events |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/events/ScriptEvent.java#L502 |
Name | Damage Cause |
Description | Possible damage causes: URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/event/entity/EntityDamageEvent.DamageCause.html
These are used in Event:entity damage, Tag:server.damage_causes, Tag:EntityTag.last_damage.cause, ... |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/events/entity/EntityDamagedScriptEvent.java#L20 |
Name | Inventory Actions |
Description | Used by some inventory world events to describe the action of the inventory event.
Actions, as described by the bukkit javadocs: CLONE_STACK A max-size stack of the clicked item is put on the cursor. COLLECT_TO_CURSOR The inventory is searched for the same material, and they are put on the cursor up to MaterialTag.max_stack_size. DROP_ALL_CURSOR The entire cursor item is dropped. DROP_ALL_SLOT The entire clicked slot is dropped. DROP_ONE_CURSOR One item is dropped from the cursor. DROP_ONE_SLOT One item is dropped from the clicked slot. HOTBAR_MOVE_AND_READD The clicked item is moved to the hotbar, and the item currently there is re-added to the player's inventory. HOTBAR_SWAP The clicked slot and the picked hotbar slot are swapped. MOVE_TO_OTHER_INVENTORY The item is moved to the opposite inventory if a space is found. NOTHING Nothing will happen from the click. PICKUP_ALL All of the items on the clicked slot are moved to the cursor. PICKUP_HALF Half of the items on the clicked slot are moved to the cursor. PICKUP_ONE One of the items on the clicked slot are moved to the cursor. PICKUP_SOME Some of the items on the clicked slot are moved to the cursor. PLACE_ALL All of the items on the cursor are moved to the clicked slot. PLACE_ONE A single item from the cursor is moved to the clicked slot. PLACE_SOME Some of the items from the cursor are moved to the clicked slot (usually up to the max stack size). SWAP_WITH_CURSOR The clicked item and the cursor are exchanged. UNKNOWN An unrecognized ClickType. |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/events/player/PlayerClicksInInventoryScriptEvent.java#L21 |
Name | Raw NBT Encoding |
Description | The item Raw_NBT property encodes and decodes raw NBT data.
For the sake of inter-compatibility, a special standard format is used to preserve data types. NBT Tags are encoded as follows: CompoundTag: (a fully formed MapTag) ListTag: list:(NBT type-code):(a fully formed ListTag) ByteArrayTag: byte_array:(a pipe-separated list of numbers) IntArrayTag: int_array:(a pipe-separated list of numbers) ByteTag: byte:(#) ShortTag: short:(#) IntTag: int:(#) LongTag: long:(#) FloatTag: float:(#) DoubleTag: double:(#) StringTag: string:(text here) EndTag: end |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/properties/item/ItemRawNBT.java#L111 |
Name | Particle Effects |
Description | All of the effects listed here can be used by Command:PlayEffect to display visual effects or play sounds
Effects: - Everything on URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Particle.html - Everything on URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Effect.html - RANDOM (chooses a random visual effect from the Particle list) |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/commands/world/PlayEffectCommand.java#L36 |
Name | Denizen Entity Types |
Description | Along with the default EntityTypes URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/entity/EntityType.html,
Denizen also adds in a few altered entities: - FAKE_ARROW: For use when you want an arrow to stay spawned at a location for any reason. - FAKE_PLAYER: Spawns a fake player (non-Citizens NPC). Use with the mechanisms "name" and "skin" to alter the respective properties. - ITEM_PROJECTILE: Use this when you want to fire any item as if it were a normal projectile. It will have the same physics (although sometimes not clientside) as arrows, and will fire the projectile hit event. |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/entity/DenizenEntityType.java#L38 |
Name | Slot Inputs |
Description | Whenever a script component requires a slot ID (such as the take command, when using '- take slot:#')
you can give the slot ID input as either a number of the 1-based index (where the first slot is 1, the second is 2, etc.) OR you can give the following names (valid for player inventories only): BOOTS: equivalent to 37 LEGGINGS: equivalent to 38 CHESTPLATE: equivalent to 39 HELMET: equivalent to 40 OFFHAND: equivalent to 41 Note that some common alternate spellings may be automatically accepted as well. |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/inventory/SlotHelper.java#L63 |
Name | Escaping System |
Description | Sometimes, 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: | = &pipe < = < > = > newline = &nl & = & ; = &sc [ = &lb ] = &rb : = &co at sign @ = &at . = &dot \ = &bs ' = &sq " = &quo ! = &exc / = &fs ยง = &ss # = &ns 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/EscapeTagBase.java#L30 |
Name | Data Actions |
Description | Several 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. 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. |
Group | Useful Lists |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/utilities/data/DataActionType.java#L5 |
Name | Player Entity Skins (Skin Blobs) |
Description | Player entities (that is, both real players and player-type NPCs), in addition to Player_Head items,
use something called a "skin blob" to determine what skin to show. A skin blob consists of an identifier (usually the player's UUID, sometimes the name), a "texture", and a "signature". The "texture" portion, despite the name, does not contain actual texture data - it contains a Base64 encoding of a JSON section that contains outlinks to real skin data. That might be a bit confusing, so here's an example: The raw "texture" data for "mcmonkey4eva"'s skin is: eyJ0aW1lc3RhbXAiOjE1NjU1NjUyNDA4NTMsInByb2ZpbGVJZCI6IjQ2MGU5NmI5N2EwZTQxNmRiMmMzNDUwODE2NGI4YjFiIiwicHJvZmlsZU5hbWUiOiJtY21vbmtleTRldmEiLCJzaWduYXR1cmVSZXF1aXJlZCI6dHJ1ZSwidGV4dH VyZXMiOnsiU0tJTiI6eyJ1cmwiOiJodHRwOi8vdGV4dHVyZXMubWluZWNyYWZ0Lm5ldC90ZXh0dXJlL2ZkMzRiM2UyN2EzZmU1MzgyN2IzN2FkNTk1NmFjY2EwOGYyODYzYzY5MjZjYzk3MTE2ZGRhMzM0ODY5N2E1YTkifX19 This is base64 encoding, which is just a way of controlling the format of binary data. When passed through a Base64 decoder, that says: {"timestamp":1565565240853,"profileId":"460e96b97a0e416db2c34508164b8b1b","profileName":"mcmonkey4eva","signatureRequired":true, "textures":{"SKIN":{"url":"http://textures.minecraft.net/texture/fd34b3e27a3fe53827b37ad5956acca08f2863c6926cc97116dda3348697a5a9"}}} As you can see, it contains: the timestamp of when the skin was added, the UUID and name, and a link to the actual skin file on Mojang's servers. The "signature" portion is a digitally encrypted signature that is used to verify a skin really was generated by Mojang. It is also represented as Base64, but cannot be decoded to anything readable. The "signature" is required for Player entity skins, but can generally be left off from Player_Head items (meaning, you can generate your own Player_Head items by base64 encoding your own JSON). The website URL:https://mineskin.org/ can be used to generate full texture+signature data from any skin file (it does this by automatically uploading the skin image to Mojang's servers for processing and signing, using a donated Minecraft account). In terms of general actual usage, skin blobs are generally meant to be read from tags and applied with mechanisms, never directly written out or read by a human, due to their complexity. A skin_blob always represents a single actual skin, as opposed to a player name/uuid, where the account owner might choose to change their skin. It should be noted that any time a skin is applied to a Player, NPC, Or Player_Head item using just a name or UUID, the server must contact Mojang's servers to requst the skin blob for that given name/uuid. With a skin blob, however, the server does not need to make any remote calls, and can apply the skin directly (However note that the client will still download the image from Mojang's servers). |
Group | Minecraft Logic |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/nms/abstracts/ProfileEditor.java#L45 |
Name | Health Trait |
Description | By default, NPCs are invulnerable, unable to be damaged. If you want your NPC
to be able to take damage, or use the left click as an interaction, it must have the health trait. The Health trait is automatically enabled if you set the damage trigger state to true. You can use the denizen vulnerable command to make your NPCs react to left click, but not take damage. - vulnerable state:false Enable Damage trigger via dScript: - trigger name:damage state:true Enable Health trait via dScript: - trait state:true health Enable Health trait via npc command: /npc health --set # (-r) Enable automatic respawn (default delay 300t): /npc health --respawndelay [delay as a duration] Set respawn location: - flag <npc> respawn_location:<location> Related Tags Tag:EntityTag.health Tag:EntityTag.formatted_health Tag:EntityTag.health_max Tag:EntityTag.health_percentage Tag:NPCTag.has_trait[health] Related Mechanisms Mechanism:EntityTag.health Mechanism:EntityTag.max_health Related Commands Command:heal Command:health Command:vulnerable Related Actions Action:on damage Action:on damaged Action:on no damage trigger |
Group | NPC Traits |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/npc/traits/HealthTrait.java#L29 |
Name | Invisible Trait |
Description | The invisible trait will allow a NPC to remain invisible, even after a server restart. It permanently applies
the invisible potion effect. Use '/trait invisible' or the 'invisible' script command to toggle this trait. Note that player-type NPCs must have '/npc playerlist' toggled to be turned invisible. Once invisible, the player-type NPCs can be taken off the playerlist. This only applies specifically to player-type NPCs. Playerlist will be enabled automatically if not set in advance, but not automatically removed. |
Group | NPC Traits |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/npc/traits/InvisibleTrait.java#L18 |
Name | Pushable Trait |
Description | By default, NPCs created will allow players to 'noclip' them, or go right through. This is to
avoid NPCs moving from their set location, but often times, this behavior may be undesired. The pushable trait allows NPCs to move when collided with, and optionally return to their original location after a specified amount of time. To enable the trait, use the '/npc pushable' command on any selected NPC. Once the trait is enabled, the '-r' option can be used to toggle returnable, and the '--delay #' option can be used to specify the number of seconds before the npc returns. Care should be taken when allowing NPCs to be pushable. Allowing NPCs to be pushed around complex structures can result in stuck NPCs. If the NPC is stuck, it may not return. Keeping a small delay, in situations like this, can be a good trade-off. Typically the lower the delay, the shorter distance a Player is able to push the NPC. The default delay is 2 seconds. The pushable trait also implements some actions that can be used in assignment scripts. This includes 'on push' and 'on push return'. |
Group | NPC Traits |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/npc/traits/PushableTrait.java#L18 |
Name | BiomeTag Objects |
Description | A BiomeTag represents a world biome type.
A list of all valid Bukkit biomes can found be at URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/block/Biome.html These use the object notation "b@". The identity format for biomes is simply the biome name, as registered in Bukkit, for example: 'desert'. This object type is flaggable. Flags on this object type will be stored in the server saves file, under special sub-key "__biomes" |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/BiomeTag.java#L26 |
Name | ChunkTag Objects |
Description | A ChunkTag represents a chunk in the world.
These use the object notation "ch@". The identity format for chunks is <x>,<z>,<world> For example, 'ch@5,3,world'. Note that the X/Z pair are chunk coordinates, not block coordinates. To convert from block coordinates to chunk coordinates, divide by 16 and round downward. Note that negative chunks are one unit lower than you might expect. To understand why, simply look at chunks on a number line... x x x x x -2 -1 b 0 a 1 2 The block 'a' at block position '1' is in chunk '0', but the block 'b' at block position '-1' is in chunk '-1'. As otherwise (if 'b' was in chunk '0'), chunk '0' would be double-wide (32 blocks wide instead of the standard 16). For example, block at X,Z 32,67 is in the chunk at X,Z 2,4 And the block at X,Z -32,-67 is in the chunk at X,Z -2,-5 This object type is flaggable. Flags on this object type will be stored in the chunk file inside the world folder. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/ChunkTag.java#L32 |
Name | ColorTag Objects |
Description | A ColorTag represents an RGB color code.
Note that a ColorTag is NOT a base dye color (used by wool, etc). That is handled by a separate naming system. These use the object notation "co@". The identity format for colors is <red>,<green>,<blue> or the name of a color. For example, 'co@50,64,128' or 'co@red'. Construction a ColorTag also accepts 'random' to pick a random RGB color, or hex code like '#FF00FF'. A list of accepted color names can be found at URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Color.html Red/green/blue values are each from 0 to 255. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/ColorTag.java#L21 |
Name | CuboidTag Objects |
Description | A CuboidTag represents a cuboidal region in the world.
The word 'cuboid' means a less strict cube. Basically: a "cuboid" is to a 3D "cube" what a "rectangle" is to a 2D "square". One 'cuboid' consists of two points: the low point and a high point. a CuboidTag can contain as many cuboids within itself as needed (this allows forming more complex shapes from a single CuboidTag). These use the object notation "cu@". The identity format for cuboids is <world>,<x1>,<y1>,<z1>,<x2>,<y2>,<z2> Multi-member cuboids can simply continue listing x,y,z pairs. For example, 'cu@space,1,2,3,4,5,6'. This object type can be noted. This object type is flaggable when it is noted. Flags on this object type will be stored in the notables.yml file. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/CuboidTag.java#L38 |
Name | EllipsoidTag Objects |
Description | An EllipsoidTag represents an ellipsoidal region in the world.
The word 'ellipsoid' means a less strict sphere. Basically: an "ellipsoid" is to a 3D "sphere" what an "ellipse" (or "oval") is to a 2D "circle". These use the object notation "ellipsoid@". The identity format for ellipsoids is <x>,<y>,<z>,<world>,<x-radius>,<y-radius>,<z-radius> For example, 'ellipsoid@1,2,3,space,7,7,7'. This object type can be noted. This object type is flaggable when it is noted. Flags on this object type will be stored in the notables.yml file. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/EllipsoidTag.java#L35 |
Name | EntityTag Objects |
Description | An EntityTag represents a spawned entity, or a generic entity type.
Note that players and NPCs are valid EntityTags, but are generally represented by the more specific PlayerTag and NPCTag objects. Note that a spawned entity can be a living entity (a player, NPC, or mob) or a nonliving entity (a painting, item frame, etc). These use the object notation "e@". The identity format for entities is a spawned entity's UUID, or an entity type. For example, 'e@abc123' or 'e@zombie'. This object type is flaggable. Flags on this object type will be stored in the world chunk files as a part of the entity's NBT. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/EntityTag.java#L53 |
Name | InventoryTag Objects |
Description | An InventoryTag represents an inventory, generically or attached to some in-the-world object.
Inventories can be generically designed using inventory script containers, and can be modified using the inventory command. These use the object notation "in@". The identity format for inventories is a the classification type of inventory to use. All other data is specified through properties. Valid inventory type classifications: "npc", "player", "crafting", "enderchest", "workbench", "entity", "location", "generic" This object type can be noted. This object type is flaggable when it is noted. Flags on this object type will be stored in the notables.yml file. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/InventoryTag.java#L54 |
Name | ItemTag Objects |
Description | An ItemTag represents a holdable item generically.
ItemTags are temporary objects, to actually modify an item in an inventory you must add the item into that inventory. ItemTags do NOT remember where they came from. If you read an item from an inventory, changing it does not change the original item in the original inventory. You must set it back in. These use the object notation "i@". The identity format for items is the basic material type name, or an item script name. Other data is specified in properties. For example, 'i@stick'. Find a list of valid materials at: URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Material.html Note that some materials on that list are exclusively for use with blocks, and cannot be held as items. This object type is flaggable. Flags on this object type will be stored in the item NBT. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/ItemTag.java#L48 |
Name | LocationTag Objects |
Description | A LocationTag represents a point in the world.
These use the object notation "l@". Note that 'l' is a lowercase 'L', the first letter in 'location'. The identity format for locations is <x>,<y>,<z>,<pitch>,<yaw>,<world> Note that you can leave off the world, and/or pitch and yaw, and/or the z value. You cannot leave off both the z and the pitch+yaw at the same time. For example, 'l@1,2.15,3,45,90,space' or 'l@7.5,99,3.2' This object type is flaggable. Flags on this object type will be stored in the chunk file inside the world folder. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/LocationTag.java#L62 |
Name | MaterialTag Objects |
Description | A MaterialTag represents a material (a type of block or item).
These use the object notation "m@". The identity format for materials is the material type name. For example, 'm@stick'. Block materials may sometimes also contain property data, for specific values on the block material such as the growth stage of a plant or the orientation of a stair block. Material types: URL:https://hub.spigotmc.org/javadocs/spigot/org/bukkit/Material.html. This object type is flaggable. Flags on this object type will be stored in the server saves file, under special sub-key "__materials" |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/MaterialTag.java#L29 |
Name | NPCTag Objects |
Description | An NPCTag represents an NPC configured through Citizens.
These use the object notation "n@". The identity format for NPCs is the NPC's id number. For example, 'n@5'. This object type is flaggable. Flags on this object type will be stored in the Citizens saves.yml file, under the 'denizen_flags' trait. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/NPCTag.java#L55 |
Name | PlayerTag Objects |
Description | A PlayerTag represents a player in the game.
These use the object notation "p@". The identity format for players is the UUID of the relevant player. This object type is flaggable. Flags on this object type will be stored in the file "plugins/Denizen/player_flags/(UUID).dat", with automatic loading only when the player is online and caching for interacting with offline player flags. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/PlayerTag.java#L57 |
Name | PluginTag Objects |
Description | A PluginTag represents a Bukkit plugin on the server.
These use the object notation "pl@". The identity format for plugins is the plugin's registered name. For example, 'pl@Denizen'. This object type is flaggable. Flags on this object type will be stored in the server saves file, under special sub-key "__plugins" |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/PluginTag.java#L21 |
Name | PolygonTag Objects |
Description | A PolygonTag represents a polygonal region in the world.
The word 'polygon' means an arbitrary 2D shape. PolygonTags, in addition to a 2D polygon, contain a minimum and maximum Y coordinate, to allow them to function in 3D. PolygonTags are NOT polyhedra. These use the object notation "polygon@". The identity format for cuboids is <world>,<y-min>,<y-max>,<x1>,<z1>,... (the x,z pair repeats for as many points as the polygon has). A PolygonTag with 4 points at right angles would cover an area also possible to be defined by a CuboidTag, however all other shapes a PolygonTag can form are unique. Compared to CuboidTags, PolygonTags are generally slower to process and more complex to work with, but offer the benefit of supporting more intricate shapes. Note that forming invalid polygons (duplicate corners, impossible shapes, etc) will not necessarily give any error message, and may cause weird results. This object type can be noted. This object type is flaggable when it is noted. Flags on this object type will be stored in the notables.yml file. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/PolygonTag.java#L35 |
Name | TradeTag Objects |
Description | Merchant trades are the parts of a special merchant inventory that is typically viewed by right clicking
a villager entity. Any number of trades can fit in a single merchant inventory. Trades are represented by TradeTags. The properties that can be used to customize a merchant trade are: result=<item> inputs=<item>(|<item>) uses=<number of uses> max_uses=<maximum number of uses> has_xp=true/false For example, the following command opens a virtual merchant inventory with two merchant trades. The first trade offers a sponge for two emeralds, can be used up to 10 times, and offers XP upon a successful transaction. The second trade has zero maximum uses and displays a barrier.
|
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/TradeTag.java#L17 |
Name | WorldTag Objects |
Description | A WorldTag represents a world on the server.
These use the object notation "w@". The identity format for worlds is the name of the world it should be associated with. For example, to reference the world named 'world1', use simply 'world1'. World names are case insensitive. This object type is flaggable. Flags on this object type will be stored in the world folder in a file named 'denizen_flags.dat', like "server/world/denizen_flags.dat". |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/WorldTag.java#L49 |
Name | ObjectTags |
Description | ObjectTags are a system put into place by Denizen that make working with things, or 'objects',
in Minecraft and Denizen easier. Many parts of scripts will require some kind of object as an argument, identifier/type, or such as in world events, part of an event name. The ObjectTags notation system helps both you and Denizen know what type of objects are being referenced and worked with. So when should you use ObjectTags? In arguments, event names, replaceable tags, configs, flags, and more! If you're just a beginner, you've probably been using them without even realizing it! ObjectTag is a broader term for a 'type' of object that more specifically represents something, such as a LocationTag or ScriptTag, often times just referred to as a 'location' or 'script'. Denizen employs many object types that you should be familiar with. You'll notice that many times objects are referenced with their 'ObjectTag notation' which is in the format of 'x@', the x being the specific notation of an object type. Example: player objects use the p@ notation, and locations use l@. This notation is automatically generated when directly displaying objects, or saving them into data files. It should never be manually typed into a script. Let's take the tag system, for example. It uses the ObjectTags system pretty heavily. For instance, every time you use <player.name> or <npc.id>, you're using a ObjectTag, which brings us to a simple clarification: Why <player.name> and not <PlayerTag.name>? That's because Denizen allows Players, NPCs and other 'in-context objects' to be linked to certain scripts. In short, <player> already contains a reference to a specific player, such as the player that died in a world event 'on player dies'. <PlayerTag.name> is instead the format for documentation, with "PlayerTag" simply indicating 'any player object here'. ObjectTags can be used to CREATE new instances of objects, too! Though not all types allow 'new' objects to be created, many do, such as ItemTags. With the use of tags, it's easy to reference a specific item, say -- an item in the Player's hand -- items are also able to use a constructor to make a new item, and say, drop it in the world. Take the case of the command/usage '- drop diamond_ore'. The item object used is a brand new diamond_ore, which is then dropped by the command to a location of your choice -- just specify an additional location argument. There's a great deal more to learn about ObjectTags, so be sure to check out each object type for more specific information. While all ObjectTags share some features, many contain goodies on top of that! |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/CommonRegistries.java#L14 |
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#L63 |
Name | Custom Objects |
Description | Custom objects are custom object types.
They use a script basis to create an object similar to the base object types (ListTag, PlayerTags, etc). 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. These use the object notation "custom@". The identity format for custom objects is the script name, followed by property syntax listing all fields with their values. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/CustomObjectTag.java#L19 |
Name | DurationTag Objects |
Description | Durations are a unified and convenient way to get a 'unit of time' throughout Denizen.
Many commands and features that require a duration can be satisfied by specifying a number and unit of time, especially command arguments that are prefixed 'duration:', etc. The unit of time can be specified by using one of the following: t=ticks (0.05 seconds), s=seconds, m=minutes (60 seconds), h=hours (60 minutes), d=days (24 hours), w=weeks (7 days), y=years (365 days). Not using a unit will imply seconds. Examples: 10s, 50m, 1d, 20. Specifying a range of duration will result in a randomly selected duration that is in between the range specified. The smaller value should be first. Examples: '10s-25s', '1m-2m'. The input of 'instant' or 'infinite' will be interpreted as 0 (for use with commands where instant/infinite logic applies). These use the object notation "d@". The identity format for DurationTags is the number of seconds, followed by an 's'. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/DurationTag.java#L18 |
Name | ElementTag Objects |
Description | ElementTags are simple objects that contain a simple bit of text.
Their main usage is within the replaceable tag system, often times returned from the use of another tag that isn't returning a specific object type, such as a location or entity. For example, <player.name> or <list[item1|item2|item3].comma_separated> will both return ElementTags. Pluses to the ElementTag system is the ability to utilize its tag attributes, which can provide a range of functionality that should be familiar from any other programming language, such as 'to_uppercase', 'split', 'replace', 'contains', and many more. See 'ElementTag.*' tags for more information. While information fetched from other tags resulting in an ElementTag is often times automatically handled, it may be desirable to utilize element attributes from text/numbers/etc. that aren't already an element object. To accomplish this, the standard 'element' tag base can be used for the creation of a new element. For example: <element[This_is_a_test].to_uppercase> will result in the value 'THIS_IS_A_TEST'. Note that while other objects often return their object identifier (p@, li@, e@, etc.), elements usually do not (except special type-validation circumstances). They will, however, recognize the object notation "el@" if it is used. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L27 |
Name | ElementTag(Boolean) |
Description | When "ElementTag(Boolean)" appears in meta documentation, this means the input/output is an ElementTag
(refer to Language:ElementTag Objects) 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#L52 |
Name | ElementTag(Number) |
Description | When "ElementTag(Number)" appears in meta documentation, this means the input/output is an ElementTag
(refer to Language:ElementTag Objects) 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 "<#>". |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ElementTag.java#L61 |
Name | ElementTag(Decimal) |
Description | When "ElementTag(Decimal)" appears in meta documentation, this means the input/output is an ElementTag
(refer to Language:ElementTag Objects) 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#L73 |
Name | ListTag Objects |
Description | A ListTag is a list of any data. It can hold any number of objects in any order.
The objects can be of any Denizen object type, including another list. List indices start at 1 (so, the tag 'get[1]' gets the very first entry) and extend to however many entries the list has (so, if a list has 15 entries, the tag 'get[15]' gets the very last entry). These use the object notation "li@". The identity format for ListTags is each item, one after the other, in order, separated by a pipe '|' symbol. For example, for a list of 'taco', 'potatoes', and 'cheese', it would be 'li@taco|potatoes|cheese|' A list with zero items in it is simply 'li@', and a list with one item is just the one item and a pipe on the end. If the pipe symbol "|" appears in a list entry, it will be replaced by "&pipe", similarly if an ampersand "&" appears in a list entry, it will be replaced by "&". This is a subset of Denizen standard escaping, see Language:Escaping System. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ListTag.java#L31 |
Name | MapTag Objects |
Description | A MapTag represents a mapping of keys to values.
Keys are plain text, case-insensitive. Values can be anything, even lists or maps themselves. Any given key can only appear in a map once (ie, no duplicate keys). Values can be duplicated into multiple keys without issue. Order of keys is preserved. Casing in keys is preserved in the object but ignored for map lookups. These use the object notation "map@". The identity format for MapTags is each key/value pair, one after the other, separated by a pipe '|' symbol. The key/value pair is separated by a slash. For example, a map of "taco" to "food", "chicken" to "animal", and "bob" to "person" would be "map@taco/food|chicken/animal|bob/person|" A map with zero items in it is simply 'map@'. If the pipe symbol "|" appears in a key or value, it will be replaced by "&pipe", a slash "/" will become "&fs", and an ampersand "&" will become "&". This is a subset of Denizen standard escaping, see Language:Escaping System. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/MapTag.java#L18 |
Name | QueueTag Objects |
Description | A QueueTag is a single currently running set of script commands.
This is not to be confused with a script path, which is a single set of script commands that can be run. There can be one, multiple, or zero queues running at any time for any given path. These use the object notation "q@". The identity format for queues is simply the queue ID. This object type is flaggable. Flags on this object type will be reinterpreted as definitions. Flags on queues should just not be used. Use definitions directly. |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/QueueTag.java#L21 |
Name | ScriptTag Objects |
Description | A ObjectTag that represents a script container. ScriptTags contain all information inside the script,
and can be used in a variety of commands that require script arguments. For example, run and inject will 'execute' script entries inside of a script container when given a matching ScriptTag object. ScriptTags also provide a way to access attributes accessed by the replaceable tag system by using the object fetcher or any other entry point to a ScriptTag object. These use the object notation "s@". The identity format for scripts is simply the script name. This object type is flaggable. Flags on this object type will be stored in the server saves file, under special sub-key "__scripts" |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L78 |
Name | TimeTag Objects |
Description | A TimeTag represents a real world date/time value.
These use the object notation "time@". The identity format for TimeTags is "yyyy/mm/dd_hh:mm:ss:mill_offset" So, for example, 'time@2020/05/23_02:20:31:123_-07:00' TimeTags can also be constructed from 'yyyy/mm/dd', 'yyyy/mm/dd_hh:mm:ss', or 'yyyy/mm/dd_hh:mm:ss:mill'. (Meaning: the offset is optional, the milliseconds are optional, and the time-of-day is optional, but if you exclude an optional part, you must immediately end the input there, without specifying more). This object type is flaggable. Flags on this object type will be stored in the server saves file, under special sub-key "__time" |
Group | Object System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/TimeTag.java#L26 |
Name | DiscordBotTag Objects |
Description | A DiscordBotTag is an object that represents a Discord bot powered by dDiscordBot.
These use the object notation "discord@". The identity format for Discord bots is the bot ID (as chosen in Command:discord). For example: mybot This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordBotTag.java#L19 |
Name | DiscordChannelTag Objects |
Description | A DiscordChannelTag is an object that represents a channel (text or voice) on Discord, either as a generic reference,
or as a bot-specific reference (the relevant guild is inherently linked, and does not need to be specified). These use the object notation "discordchannel@". The identity format for Discord channels is the bot ID (optional), followed by the channel ID (required). For example: 1234 Or: mybot,1234 This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat, under special sub-key "__channels" |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordChannelTag.java#L21 |
Name | DiscordEmbedTag Objects |
Description | A DiscordEmbedTag is an object that represents a Discord embed for use with dDiscordBot.
These use the object notation "discordembed@". The identity format for Discord embeds is a map of embed data. Do not alter raw embed data, use the with.as tag instead. |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordEmbedTag.java#L26 |
Name | DiscordGroupTag Objects |
Description | A DiscordGroupTag is an object that represents a group on Discord, either as a generic reference,
or as a bot-specific reference. Note that the correct name for what we call here a 'group' is inconsistent between different people. The Discord API calls it a "guild" (for historical reasons, not called that by *people* anymore usually), messages in the Discord app call it a "server" (which is a convenient name but is factually inaccurate, as they are not servers), many people will simply say "a Discord" (which is awkward for branding and also would be confusing if used in documentation). So we're going with "group" (which is still confusing because "group" sometimes refers to DM groups, but... it's good enough). These use the object notation "discordgroup@". The identity format for Discord groups is the bot ID (optional), followed by the guild ID (required). For example: 1234 Or: mybot,1234 This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat, under special sub-key "__guilds" |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordGroupTag.java#L24 |
Name | DiscordMessageTag Objects |
Description | A DiscordMessageTag is an object that represents a message already sent on Discord, either as a generic reference,
or as a bot-specific reference. Note that this is not used for messages that *are going to be* sent. Note that this often does not contain data for messages that have been deleted (unless that data is cached). These use the object notation "discordmessage@". The identity format for Discord messages is the bot ID (optional), followed by the channel ID (optional), followed by the message ID (required). For example: 1234 Or: 12,1234 Or: mybot,12,1234 This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat, under special sub-key "__messages" |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordMessageTag.java#L25 |
Name | DiscordReactionTag Objects |
Description | A DiscordReactionTag is an object that represents a reaction to a message already sent on Discord, as a generic reference.
These use the object notation "discordreaction@". The identity format for Discord reactions is the bot ID, followed by the channel ID, followed by the message ID, followed by the reaction ID. Or: mybot,12,1234,99 The reaction ID for custom reactions is an ID number, and for default emojis is the unicode text format of the emoji. This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat, under special sub-key "__reactions" |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordReactionTag.java#L25 |
Name | DiscordRoleTag Objects |
Description | A DiscordRoleTag is an object that represents a role on Discord, either as a generic reference,
or as a guild-specific reference, or as a bot+guild-specific reference. These use the object notation "discordrole@". The identity format for Discord roles is the bot ID (optional), followed by the guild ID (optional), followed by the role ID (required). For example: 4321 Or: 1234,4321 Or: mybot,1234,4321 This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat, under special sub-key "__roles" |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordRoleTag.java#L22 |
Name | DiscordUserTag Objects |
Description | A DiscordUserTag is an object that represents a user (human or bot) on Discord, either as a generic reference,
or as a bot-specific reference. These use the object notation "discorduser@". The identity format for Discord users is the bot ID (optional), followed by the user ID (required). For example: 1234 Or: mybot,1234 This object type is flaggable. Flags on this object type will be stored in: plugins/dDiscordBot/flags/bot_(botname).dat, under special sub-key "__users" |
Group | Object System |
Requires | dDiscordBot |
Source | https://github.com/DenizenScript/dDiscordBot/blob/master/src/main/java/com/denizenscript/ddiscordbot/objects/DiscordUserTag.java#L25 |
Name | Entity Color Types |
Description | This is a quick rundown of the styling information used to handle the coloration of a mob,
in both Tag:EntityTag.color and Mechanism:EntityTag.color. The list of values can be gotten in-script via Tag:EntityTag.allowed_colors. For horses, the format is COLOR|STYLE, where COLOR is BLACK, BROWN, CHESTNUT, CREAMY, DARK_BROWN, GRAY, or WHITE. and where STYLE is WHITE, WHITE_DOTS, WHITEFIELD, BLACK_DOTS, or NONE. For rabbits, the types are BROWN, WHITE, BLACK, BLACK_AND_WHITE, GOLD, SALT_AND_PEPPER, or THE_KILLER_BUNNY. For cats (not ocelots), the format is TYPE|COLOR (see below). The types are TABBY, BLACK, RED, SIAMESE, BRITISH_SHORTHAIR, CALICO, PERSIAN, RAGDOLL, WHITE, JELLIE, and ALL_BLACK. For parrots, the types are BLUE, CYAN, GRAY, GREEN, or RED. For llamas, the types are CREAMY, WHITE, BROWN, and GRAY. For mushroom_cows, the types are RED and BROWN. For foxes, the types are RED and SNOW. For pandas, the format is MAIN_GENE|HIDDEN_GENE. The gene types are NORMAL, LAZY, WORRIED, PLAYFUL, BROWN, WEAK, and AGGRESSIVE. For villagers, the types are DESERT, JUNGLE, PLAINS, SAVANNA, SNOW, SWAMP, and TAIGA. For tropical_fish, the input is PATTERN|BODYCOLOR|PATTERNCOLOR, where BodyColor and PatterenColor are both DyeColor (see below), and PATTERN is KOB, SUNSTREAK, SNOOPER, DASHER, BRINELY, SPOTTY, FLOPPER, STRIPEY, GLITTER, BLOCKFISH, BETTY, is CLAYFISH. For sheep, wolf, and shulker entities, the input is a Dye Color. For Tipped Arrow entities, the input is a ColorTag. For all places where a DyeColor is needed, the options are: BLACK, BLUE, BROWN, CYAN, GRAY, GREEN, LIGHT_BLUE, LIGHT_GRAY, LIME, MAGENTA, ORANGE, PINK, PURPLE, RED, WHITE, or YELLOW. |
Group | Properties |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/properties/entity/EntityColor.java#L196 |
Name | Virtual Inventories |
Description | Virtual inventories are inventories that have no attachment to anything within the world of Minecraft.
They can be used for a wide range of purposes - from looting fallen enemies to serving as interactive menus with item 'buttons'. In Denizen, all noted inventories (saved by the Note command) are automatically converted into a virtual copy of the saved inventory. This enables you to open and edit the items inside freely, with automatic saving, as if it were a normal inventory. Noting is not the only way to create virtual inventories, however. Using 'generic' along with inventory properties will allow you to create temporary custom inventories to do with as you please. The properties that can be used like this are: size=<size> contents=<item>|... title=<title> holder=<inventory type> For example, the following task script opens a virtual inventory with 18 slots, where the second slot is a snowball, all the rest are empty, and the title is "My Awesome Inventory" with some colors in it.
|
Group | Inventory System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/commands/item/InventoryCommand.java#L38 |
Name | Assignment Script Containers |
Description | Assignment script-containers provide functionality to NPCs by 'assignment' of the container. Assignment
scripts are meant to be used when customizing the normal behavior of NPCs. This can be used on a 'per-NPC' basis, but the encouraged approach is to design assignment scripts in a way that they can be used for multiple NPCs, perhaps with the use of constants or flags to determine specific information required by the scripts. Features unique to assignment script-containers include 'actions' and 'interact script' assignment. Like any script, the ability to run local utility scripts can be accomplished as well. This allows fully interactive NPCs to be built purely with Assignment Scripts, and for advanced situations, world scripts and interact scripts can provide more functionality. See also Language:interact script containers Basic structure of an assignment script:
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/AssignmentScriptContainer.java#L9 |
Name | Book Script Containers |
Description | Book script containers are similar to item script containers, except they are specifically
for the book items. They work with with the ItemTag object, and can be fetched with the Object Fetcher by using the ItemTag constructor book_script_name Example: - give <player> my_book
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/BookScriptContainer.java#L19 |
Name | Command Script Containers |
Description | Command script containers allow you to register your own custom commands to the server.
This also allows the command to show up in the '/help' command, with some info on the command. Note that existing names or aliases from other plugins will be overridden. If you want to run a script at the same time as an existing command, see Event:on command. The following is the format for the container. The required keys are 'name:', 'description:', 'usage:', and 'script:' All other keys can be excluded if unneeded. If you are not intentionally setting a specific value for the other keys, it is strongly recommended that you simply not include them at all. Please note that 'name:' is the true name of the command (written by users), and 'usage:' is for documentation in the '/help' command. These two options should almost always show the same name.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/CommandScriptContainer.java#L28 |
Name | Economy Script Containers |
Description | Economy script containers
Economy script containers provide a Vault economy, which can be used in scripts by Tag:PlayerTag.money and Command:money and as well by any other plugin that relies on economy functionality (such as shop plugins). Note that vault economy bank systems are not currently supported. Per-world economies are also not currently supported. Note that in most cases, you do not want to have multiple economy providers, as only one will actually be in use. ALL SCRIPT KEYS ARE REQUIRED.
|
Group | Script Container System |
Requires | Vault |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/EconomyScriptContainer.java#L29 |
Name | Entity Script Containers |
Description | Entity script containers are an easy way to pre-define custom entities for use within scripts. Entity
scripts work with the EntityTag object, and can be fetched with the Object Fetcher by using the EntityTag constructor of simply the script name. Example: - spawn <player.location> MyEntity The following is the format for the container. Except for the 'entity_type' key (and the required 'type' key), all other keys are optional. You can also include a 'custom' key to hold any custom data attached to the script.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/EntityScriptContainer.java#L23 |
Name | Format Script Containers |
Description | Format script containers are very simple script containers used for formatting messages, usually with the 'narrate' command.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/FormatScriptContainer.java#L16 |
Name | Interact Script Containers |
Description | Interact script containers are used to handle NPC triggers.
Interact scripts must be referenced from an assignment script container to be of any use. See Language:assignment script containers. The only required key on a task script container is the 'steps:' key. Within the steps key is a list of steps, where the first step is '1', 'default', or any step that contains a '*' symbol. After that, any steps must be 'zapped' to via the zap command: Command:zap. Each step contains a list of trigger types that it handles, and the relevant handling that the given trigger makes available. Refer to Language:interact script triggers for documentation about the triggers available. Any triggers used must be enabled in Action:assignment by Command:trigger. Note that script commands ran in interact scripts by default have a delay between each command. To override this delay, set 'speed: 0' on the container or change the relevant config setting.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/InteractScriptContainer.java#L17 |
Name | Inventory Script Containers |
Description | Inventory script containers are an easy way to pre-define custom inventories for use within scripts.
Inventory scripts work with the InventoryTag object, and can be fetched with the Object Fetcher by using the InventoryTag constructor InventoryTag_script_name. Example: - inventory open d:MyInventoryScript The following is the format for the container. The 'inventory:' key is required, other keys vary based on the type. Some types will require you define either 'size:' or 'slots:' (or both). 'Procedural items:' and 'definitions:' are optional, and should only be defined if needed.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/InventoryScriptContainer.java#L25 |
Name | Item Script Containers |
Description | Item script containers are an easy way to pre-define custom items for use within scripts. Item
scripts work with the ItemTag object, and can be fetched with the Object Fetcher by using the ItemTag constructor ItemTag_script_name. Example: - drop <player.location> super_dooper_diamond The following is the format for the container. Except for the 'material' key (and the dScript required 'type' key), all other keys are optional.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/ItemScriptContainer.java#L31 |
Name | Map Script Containers |
Description | Map scripts allow you define custom in-game map items, for usage with the map command.
The following is the format for the container.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/MapScriptContainer.java#L22 |
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#L18 |
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#L89 |
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#L154 |
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 Tag: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 | Procedure Script Containers |
Description | Procedure 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.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/ProcedureScriptContainer.java#L8 |
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 Command:run or Command: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#L14 |
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.
|
Group | Script Container System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/containers/core/WorldScriptContainer.java#L10 |
Name | Interact Script Triggers |
Description | Interact script triggers are the most basic components of standard NPC scripting.
They're very useful for NPCs that give quests or have other very basic interactions with players. While less powerful that other tools that Denizen provides, they can be very straightforward and clear to use in many simpler cases. Note that triggers have a default cooldown system built in to prevent users from clicking too rapidly. However these are very short cooldowns by default - when you need a longer cooldown, use Command:cooldown or Command:engage. Triggers go in Language:interact script containers. The available default trigger types are Language:click triggers, Language:damage triggers, Language:chat triggers, and Language:proximity triggers. |
Group | NPC Interact Scripts |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/InteractScriptContainer.java#L63 |
Name | Chat Triggers |
Description | Chat Triggers are triggered when when a player chats to the NPC (usually while standing close to the NPC and facing the NPC).
Interact scripts are allowed to define a list of possible messages a player may type and the scripts triggered in response. Within any given step, the format is then as follows:
|
Group | NPC Interact Scripts |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/triggers/core/ChatTrigger.java#L40 |
Name | Click Triggers |
Description | Click Triggers are triggered when when a player right clicks the NPC.
These are very basic with no extraneous complexity. |
Group | NPC Interact Scripts |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/triggers/core/ClickTrigger.java#L22 |
Name | Damage Triggers |
Description | Damage Triggers are triggered when when a player left clicks the NPC.
Despite the name, these do not actually require the NPC take any damage, only that the player left clicks the NPC. In scripts, use <context.damage> to measure how much damage was done to the NPC (though note that invincible NPCs don't necessarily take any damage even when this is non-zero). These are very basic with no extraneous complexity. |
Group | NPC Interact Scripts |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/triggers/core/DamageTrigger.java#L28 |
Name | Proximity Triggers |
Description | Proximity Triggers are triggered when when a player moves in the area around the NPC.
Proximity triggers must have a sub-key identifying what type of proximity trigger to use. The three types are "entry", "exit", and "move". Entry and exit do exactly as the names imply: Entry fires when the player walks into range of the NPC, and exit fires when the player walks out of range. Move is a bit more subtle: it fires very rapidly so long as a player remains within range of the NPC. This is useful for eg script logic that needs to be constantly updating whenever a player is nearby (eg a combat NPC script needs to constantly update its aim). The radius that the proximity trigger detects at is set by Command:trigger. |
Group | NPC Interact Scripts |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/triggers/core/ProximityTrigger.java#L21 |
Name | Tick |
Description | A 'tick' is usually referred to as 1/20th of a second, the speed at which Minecraft servers update
and process everything on them. |
Group | Common Terminology |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/CommonRegistries.java#L52 |
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#L11 |
Name | Denizen Text Formatting |
Description | Denizen provides a variety of special chat format options like "on_hover" and "on_click".
These options exist within Denizen and do not appear in the historical Minecraft legacy chat format that most plugins and systems read. That legacy system has 16 colors (0-9, A-F) and a few toggleable formats (bold, italic, etc). It does not contain anything that needs more than just an on/off. Modern Minecraft, however, supports a JSON based "raw" message format that can do click events, hover events, full RGB colors, etc. Denizen therefore has its own internal system that works like the legacy format system, but also supports the new options normally only available as 'raw JSON'. Because it is entirely processed within Denizen, these options only work within Denizen, when performing actions that support raw JSON input. This magic tool exists to let you write messages without having to write the messy JSON. Be aware that many inputs do not support raw JSON, and as such are limited only the historical Minecraft legacy format. Also be aware that click events, hover events, etc. are exclusively limited to the chat bar and the pages of books, as you cannot mouse over anything else. Also note that RGB colors use a format that Spigot invented, meaning they will work in places that use Spigot's parser OR Denizen's version, but nowhere that uses the vanilla format still. |
Group | Denizen Magic |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/FormattedTextHelper.java#L17 |
Name | denizen permissions |
Description | The following is a list of all permission nodes Denizen uses within Bukkit.
denizen.clickable # use the 'denizenclickable' command, which is automatically executed when using Command:clickable denizen.basic # use the basics of the /denizen command denizen.ex # use the /ex command denizen.debug # use the /denizen debug command denizen.submit # use the /denizen submit command Additionally: denizen.npc.health, denizen.npc.sneak, denizen.npc.effect, denizen.npc.fish, denizen.npc.sleep, denizen.npc.stand, denizen.npc.sit, denizen.npc.nameplate, denizen.npc.nickname, denizen.npc.trigger, denizen.npc.assign, denizen.npc.constants, denizen.npc.pushable However, we recommend just giving op to whoever needs to access Denizen - they can op themselves through Denizen anyway, why not save the trouble? ( EG, /ex execute as_server "op <player.name>" ) |
Group | Console Commands |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/command/DenizenCommandHandler.java#L28 |
Name | /denizen submit command |
Description | Use the '/denizen submit' command with '/denizen debug -r' to record debug output and post it online for assisting developers to see.
To begin recording, simply use '/denizen debug -r'. After that, any debug output sent to the console and any player chat will be added to an internal record. Once enabled, you should then fire off scripts and events that aren't working fully. Finally, you use the '/denizen submit' command to take all the recording information and paste it to an online pastebin hosted by the Denizen team. It will give you back a direct link to the full debug output, which you can view yourself and send to other helpers without trouble. There is no limit to the recording size, to prevent any important information from being trimmed away. Be careful not to leave debug recording enabled by accident, as it may eventually begin using up large amounts of memory. (The submit command will automatically disable recording, or you can instead just use '/denizen debug -r' again.) |
Group | Console Commands |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/command/DenizenCommandHandler.java#L51 |
Name | /denizen debug command |
Description | Using the /denizen debug command interfaces with Denizen's debugger to allow control over debug messages.
To enable debugging mode, simply type '/denizen debug'. While debug is enabled, all debuggable scripts, and any invoked actions, will output information to the console as they are executed. By default, all scripts are debuggable while the debugger is enabled. To disable a script specifically from debugging, simply add the 'debug:' node with a value of 'false' to your script container. This is typically used to silence particularly spammy scripts. Any kind of script container can be silenced using this method. To stop debugging, simply type the '/denizen debug' command again. This must be used without any additional options. A message will be sent to show the current status of the debugger. Note: you should almost NEVER disable debug entirely. Instead, always disable it on a per-script basis. If debug is globally disabled, that will hide important error messages, not just normal debug output. There are also several options to further help debugging. To use an option, simply attach them to the /denizen debug command. One option, or multiple options can be used. For example: /denizen debug -sbi '-c' enables/disables color. This is sometimes useful when debugging with a non-color console. '-r' enables recording mode. See also: /denizen submit command '-s' enables/disables stacktraces generated by Denizen. We might ask you to enable this when problems arise. '-b' enables/disables the ScriptBuilder debug. When enabled, Denizen will show info on script and argument creation. Warning: Can be spammy. '-n' enables/disables debug trimming. When enabled, messages longer than 1024 characters will be 'snipped'. '-i' enables/disables source information. When enabled, debug will show where it came from (when possible). '-p' enables/disables packet debug logging. When enabled, all packets sent to players (from anywhere) will be logged to console. '-f' enables/disables showing of future warnings. When enabled, future warnings (such as upcoming deprecations) will be displayed in console logs. '-v' enables/disables advanced verbose log output. This will *flood* your console super hard. '-o' enables/disables 'override' mode. This will display all script debug, even when 'debug: false' is set for scripts. '-l' enables/disables script loading information. When enabled, '/ex reload' will produce a potentially large amount of debug output. |
Group | Console Commands |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/command/DenizenCommandHandler.java#L88 |
Name | /ex command |
Description | The '/ex' command is an easy way to run a single denizen script command in-game.
'Ex' is short for 'Execute'. Its syntax, aside from '/ex' is exactly the same as any other Denizen script command. When running a command, some context is also supplied, such as '<player>' if being run by a player (versus the console), as well as '<npc>' if a NPC is selected by using the '/npc sel' command. By default, ex command debug output is sent to the player that ran the ex command (if the command was ran by a player). To avoid this, use '-q' at the start of the ex command. Like: /ex -q narrate "wow no output" The '/ex' command creates a new queue each time it's run, meaning for example '/ex define' would do nothing, as the definition will be lost immediately. If you need to sustain a queue between multiple executions, use '/exs' ("Execute Sustained"). A sustained queue will use the same queue on every execution until the queue stops (normally due to '/exs stop'). Be warned that waits will block the sustained queue - eg '/exs wait 10m' will make '/exs' effectively unusable for 10 minutes. Examples: /ex flag <player> test_flag:! /ex run npc_walk_script Need to '/ex' a command as a different player or NPC? Use Language:The Player and NPC Arguments. Examples: /ex narrate player:<[aplayer]> 'Your health is <player.health.formatted>.' /ex walk npc:<[some_npc]> <player.cursor_on> |
Group | Console Commands |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/command/ExCommandHandler.java#L39 |
Name | /npc pushable command |
Description | The '/npc pushable' command controls a NPCs Pushable Trait. When a NPC is 'pushable', the NPC
will move out of the way when colliding with another LivingEntity. Pushable NPCs have 3 different settings available: Toggled, Returnable, and Delay. When an NPCs Pushable Trait is toggled off, it will not function. Entities which collide may occupy the same space. To toggle pushable on or off, use the Bukkit command: /npc pushable -t Setting the NPC as 'returnable' will automatically navigate the NPC back to its original location after a specified delay. If not returnable, NPCs will retain their position after being moved. /npc pushable -r To change the delay of a returnable NPC, use the following Bukkit Command, specifying the number of seconds in which the delay should be. /npc pushable --delay # It is possible to use multiple arguments at once. For example: /npc pushable -t -r --delay 10 Note: If allowed to move in undesirable areas, the NPC may be un-returnable if the navigator cancels navigation due to being stuck. Care should be taken to ensure a safe area around the NPC. See also: 'pushable trait' |
Group | Console Commands |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/command/NPCCommandHandler.java#L32 |
Name | /npc constant command |
Description | The /npc constants command configures a NPC's constants. Uses Denizen's ConstantTrait to keep track of
NPC-specific constants. This provides seamless integration with an assignment script's 'Default Constants' in which text variables can be stored and retrieved with the use of 'replaceable tags', or API. Constants set at the NPC level override any constants from the NPC's assignment script. Constants may be used in several ways: Setting, Removing, and Viewing To set a constant, all that is required is a name and value. Use the Bukkit command in the following manner: (Note the use of quotes on multi world values) /npc constant --set constant_name --value 'multi word value' Removing a constant from an NPC only requires a name. Note: It is not possible to remove a constant set by the NPCs Assignment Script, except by modifying the script itself. /npc constant --remove constant_name Viewing constants is easy, just use '/npc constant #', specifying a page number. Constants which have been overridden by the NPC are formatted with a strike-through to indicate this case. To reference a constant value, use the replaceable tag to get the NPCs 'constant' attribute. For example: <npc.constant[constant_name]>. Constants may also have other tags in their value, which will be replaced whenever the constant is used, allowing the use of dynamic information. |
Group | Console Commands |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/command/NPCCommandHandler.java#L118 |
Name | The Player and NPC Arguments |
Description | The "player:<player>" and "npc:<npc>" arguments are special meta-arguments that are available for all commands, but are only useful for some.
They are written like: - give stick player:<server.flag[some_player]> or: - assign set script:MyScript npc:<entry[save].created_npc> Denizen tracks a "linked player" and a "linked NPC" in queues and the commands within. Many commands automatically operate on the linked player/NPC or by default or exclusively (for example, "give" defaults to giving items to the linked player but that can be changed with the "to" argument, "assignment" exclusively changes the assignment of the linked NPC, and that cannot be changed except by the global NPC argument). When the player argument is used, it sets the linked player for the specific command it's on. This is only useful for commands that default to operating on the linked player. This can also be useful with the "run" command to link a specific player to the new queue. The NPC argument is essentially equivalent to the player argument, but for the linked NPC instead of the linked player. These arguments will also affect tags (mainly "<player>" and "<npc>") in the same command line (regardless of argument order). If you need to use the original player/NPC in a tag on the same line, use the define command to track it. |
Group | Script Command System |
Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/implementation/DenizenCoreImplementation.java#L178 |
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. |
Group | Script Command System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/CommandExecutor.java#L40 |
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 notable 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#L47 |
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 | 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#L22 |
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#L38 |
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#L48 |
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 URL: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 '.' key, 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 '__scripts' which is where script flags are stored inside of server flags, and '__interact_step' which is used for interact script steps, related to Command:zap, and '__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 (those 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. |
Group | Denizen Scripting Language |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/core/FlagCommand.java#L28 |
Name | Comparable |
Description | A Comparable is a method that the If command, While command, and 'element.is[...].to[...]' tag uses to compare objects.
These are usually written in the format "VALUE OPERATOR VALUE". For example, if you use ">=" as the operator, and "3" and "5" as the values, you'd write "3 >= 5", which would return false (as 3 is NOT greater-than-or-equal-to 5). For a list of valid operators and their usages, see Language:operator. |
Group | Comparables |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/Comparable.java#L15 |
Name | Operator |
Description | An operator is the type of comparison that a comparable will check. Not all types of
comparables are compatible with all operators. See Language:comparable for more information. Available Operators include: "Equals" is written as "==" "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". Note: When using an operator in a replaceable tag (such as <ElementTag.is[...].than[...]>), 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: Command:if |
Group | Comparables |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/Comparable.java#L29 |
Name | Tag Fallbacks |
Description | Tag fallbacks (AKA "tag alternatives") are a system designed to allow scripters to automatically handle tag errors.
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||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||Fallback here>". For another example, "<player.flag[myflag]||0>" returns either the value of the flag, or "0" if the flag is not present (or if there's no player). This is particularly useful for things like checking whether an object exists / 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?
|
Group | Tag System |
Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/Attribute.java#L337 |
Name | AreaShopTag Objects |
Description | An AreaShopTag represents an AreaShop shop.
These use the object notation "areashop@". The identity format for shops is <shop_name> For example, 'areashop@my_shop'. |
Group | Depenizen Object Types |
Requires | Depenizen, AreaShop |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/areashop/AreaShopTag.java#L19 |
Name | BigDoorsDoorTag Objects |
Description | A BigDoorsDoorTag represents a Big Doors door.
These use the object notation "bigdoor@". The identity format for a door is it's Door ID as a number. NOT the name of the door you have set. For example, 'bigdoor@1'. |
Group | Depenizen Object Types |
Requires | Depenizen, Big Doors |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/bigdoors/BigDoorsDoorTag.java#L22 |
Name | FactionTag Objects |
Description | A FactionTag represents a Factions faction.
These use the object notation "faction@". The identity format for factions is <faction_name> For example, 'faction@my_faction'. |
Group | Depenizen Object Types |
Requires | Depenizen, Factions |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/factions/FactionTag.java#L21 |
Name | NationTag Objects |
Description | A NationTag represents a Factions nation.
These use the object notation "nation@". The identity format for nations is <nation_name> For example, 'nation@my_nation'. |
Group | Depenizen Object Types |
Requires | Depenizen, Factions |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/factions/NationTag.java#L19 |
Name | GriefPreventionClaimTag Objects |
Description | A GriefPreventionClaimTag represents a GriefPrevention claim.
These use the object notation "gpclaim@". The identity format for claims is <claim_id> For example, 'gpclaim@1234'. |
Group | Depenizen Object Types |
Requires | Depenizen, GriefPrevention |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/griefprevention/GriefPreventionClaimTag.java#L26 |
Name | JobsJobTag Objects |
Description | A JobsJobTag represents a Jobs job.
These use the object notation "job@". The identity format for jobs is <job_name> For example, 'job@job_name'. |
Group | Depenizen Object Types |
Requires | Depenizen, Jobs |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/jobs/JobsJobTag.java#L18 |
Name | LibsDisguiseTag Objects |
Description | A LibsDisguiseTag represents a LibsDisguises disguise type.
These use the object notation "libsdisguise@". The identity format for disguises is <disguise_name> For example, 'libsdisguise@zombie'. |
Group | Depenizen Object Types |
Requires | Depenizen, LibsDisguises |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/libsdisguises/LibsDisguiseTag.java#L17 |
Name | LuckPermsTrackTag Objects |
Description | A LuckPermsTrackTag represents a LuckPerms track.
These use the object notation "luckpermstrack@". The identity format for tracks is <track_name> For example, 'luckpermstrack@my_track'. |
Group | Depenizen Object Types |
Requires | Depenizen, LuckPerms |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/luckperms/LuckPermsTrackTag.java#L23 |
Name | PartyTag Objects |
Description | A PartyTag represents an McMMO party.
These use the object notation "party@". The identity format for parties is <party_name> For example, 'party@my_party'. |
Group | Depenizen Object Types |
Requires | Depenizen, McMMO |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/mcmmo/PartyTag.java#L20 |
Name | MobArenaArenaTag Objects |
Description | A MobArenaArenaTag represents a mob arena in the world.
These use the object notation "mobarena@". The identity format for arenas is <arena_name> For example, 'mobarena@my_arena'. |
Group | Depenizen Object Types |
Requires | Depenizen, MobArena |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/mobarena/MobArenaArenaTag.java#L18 |
Name | MythicMobsMobTag Objects |
Description | A MythicMobsMobTag represents a Mythic mob entity in the world.
These use the object notation "mythicmob@". The identity format for MythicMobsMobTag is <uuid> For example, 'mythicmob@1234-1234-1234'. |
Group | Depenizen Object Types |
Requires | Depenizen, MythicMobs |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/mythicmobs/MythicMobsMobTag.java#L27 |
Name | MythicSpawnerTag Objects |
Description | A MythicSpawnerTag represents a MythicMobs spanwer in the world.
These use the object notation "mythicspawner@". The identity format for a MythicSpawner is its name. For example, 'mythicspawner@AngrySludgeSpawner1'. |
Group | Depenizen Object Types |
Requires | Depenizen, MythicMobs |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/mythicmobs/MythicSpawnerTag.java#L29 |
Name | PlotSquaredPlotTag Objects |
Description | A PlotSquaredPlotTag represents a PlotSquared plot in the world.
These use the object notation "plotsquaredplot@". The identity format for plots is <x>,<z>,<world> For example, 'plotsquaredplot@5,10,Hub'. |
Group | Depenizen Object Types |
Requires | Depenizen, PlotSquared |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/plotsquared/PlotSquaredPlotTag.java#L25 |
Name | PVPArenaArenaTag Objects |
Description | A PVPArenaArenaTag represents a PvP Arena in the world.
These use the object notation "pvparena@". The identity format for arenas is <arena_name> For example, 'pvparena@myarena'. |
Group | Depenizen Object Types |
Requires | Depenizen, PvPArena |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/pvparena/PVPArenaArenaTag.java#L17 |
Name | ResidenceTag Objects |
Description | A ResidenceTag represents a Residence in the world.
These use the object notation "residence@". The identity format for residences is <residence_name> For example, 'residence@myresidence'. |
Group | Depenizen Object Types |
Requires | Depenizen, Residence |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/residence/ResidenceTag.java#L17 |
Name | ShopKeeperTag Objects |
Description | A ShopKeeperTag represents a ShopKeeper entity in the world.
These use the object notation "shopkeeper@". The identity format for shopkeepers is <uuid> For example, 'shopkeeper@1234-1234-1234'. |
Group | Depenizen Object Types |
Requires | Depenizen, Shopkeepers |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/shopkeepers/ShopKeeperTag.java#L27 |
Name | SkillAPIClassTag Objects |
Description | A SkillAPIClassTag represents a SkillAPI class.
These use the object notation "skillapiclass@". The identity format for regions is <class_name> For example, 'skillapiclass@myclass'. |
Group | Depenizen Object Types |
Requires | Depenizen, SkillAPI |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/skillapi/SkillAPIClassTag.java#L14 |
Name | TownTag Objects |
Description | A TownTag represents a Towny town in the world.
These use the object notation "town@". The identity format for towns is <town_name> For example, 'town@mytown'. |
Group | Depenizen Object Types |
Requires | Depenizen, Towny |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/towny/TownTag.java#L24 |
Name | WorldGuardRegionTag Objects |
Description | A WorldGuardRegionTag represents a WorldGuard region in the world.
These use the object notation "region@". The identity format for regions is <region_name>,<world_name> For example, 'region@spawnland,Hub'. |
Group | Depenizen Object Types |
Requires | Depenizen, WorldGuard |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/objects/worldguard/WorldGuardRegionTag.java#L27 |
Name | MythicMobs Additions |
Description | Depenizen adds additional features to Mythic Mobs, 2 Targeters, and a Condition.
Depenizen provides two additional targeters via the MythicMobs API: @DenizenEntity is an entity-based targeter, @DenizenLocation is a location-based targeter. Both targeters can parse tags; they accept input of either an EntityTag or LocationTag respectively. Both targeters also support returning ListTags containing their respective tag types. Both targeters provide <context.entity> as an EntityTag of the caster. Conditions provide different contexts depending on their usage. The syntax for calling a Denizen tag as a condition is DenizenCondition. The tag should return an ElementTag of a boolean value (true or false). <context.location> is available for location-based checks, <context.entity> is available for for entity- and caster-based checks, and <context.target> is available for target-based checks. NOTE: TriggerConditions are NOT currently supported. Usage Examples Exmaple 1: @DenizenEntity{tag=<context.entity.location.find.players.within[30].filter[has_flag[marked]]>} Example 2: @DenizenLocation{tag=<context.entity.location.find.surface_blocks.within[30].random[5]>} Example 3: @DenizenEntity{tag=<proc[SomeProcScript]>} Conditions: - denizencondition{tag=<context.entity.location.find.players.within[30].is_empty.not>} |
Group | Depenizen External Additions |
Source | https://github.com/DenizenScript/Depenizen/blob/master/src/main/java/com/denizenscript/depenizen/bukkit/utilities/mythicmobs/MythicMobsLoaders.java#L18 |