foreach out of 3939 meta-documentation entries...| Name | Foreach |
| Related Guide Page | https://guide.denizenscript.com/guides/basics/loops.html |
| Syntax | foreach [stop/next/<object>|...] (as:<name>) (key:<name>) [<commands>] |
| Short Description | Loops through a ListTag, running a set of commands for each item. |
| Full Description | Loops through a ListTag of any type. For each item in the ListTag, the specified commands will be ran for that list entry.
Alternately, specify a map tag to loop over the set of key/value pairs in the map, where the key will be <[key]> and the value will be <[value]>. Specify "key:<name>" to set the key definition name (if unset, will be "key"). Specify "as:<name>" to set the value definition name (if unset, will be "value"). Use "as:__player" to change the queue's player link, or "as:__npc" to change the queue's NPC link. Note that a changed player/NPC link persists after the end of the loop. To end a foreach loop, do - foreach stop To jump immediately to the next entry in the loop, do - foreach next Note that many commands and tags in Denizen support inputting a list directly, making foreach redundant for many simpler cases. Note that if you delay the queue (such as with wait or ~waitable) inside a foreach loop, the loop can't process the next entry until the delay is over. This can lead to very long waits if you have a long list and a wait directly in the loop, as the total delay is effectively multiplied by the number of iterations. Use run if you want to run logic simultaneously for many entries in a list in a way that allows them to separately wait without delaying each other. |
| Related Tags | <[value]> to get the current item in the loop
<[loop_index]> to get the current loop iteration number
|
| Usage Example | |
| Usage Example | |
| Usage Example | |
| Group | queue |
| Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/queue/ForeachCommand.java#L31 |
| Name | Attribute Modifiers |
| Description | In minecraft, the "attributes" system defined certain core numerical values on entities, such as max health or attack damage.
The value of an "attribute" is determined by its "base value" modified mathematically by each of its "attribute modififers". "Attribute modifiers" can be added either directly to the entity, or onto items - when on an item, an entity can equip it into the correct slot to automatically apply the modifier. These can be read via such tags as EntityTag.attribute_modifiers, ItemTag.attribute_modifiers, EntityTag.has_attribute, EntityTag.attribute_value, EntityTag.attribute_base_value, EntityTag.attribute_default_value, ... These can be modified by such mechanisms as EntityTag.attribute_base_values, EntityTag.attribute_modifiers, EntityTag.add_attribute_modifiers, EntityTag.remove_attribute_modifiers, ItemTag.attribute_modifiers, ItemTag.add_attribute_modifiers, ItemTag.remove_attribute_modifiers, ... The input format of each of the 'add' and set mechanisms is slightly complicated: a MapTag where the keys are attribute names, and values are a ListTag of modifiers, where each modifier is itself a MapTag with required keys 'operation' and 'amount', and additionally: Before MC 1.21: optional 'name', 'slot', and 'id' keys. The default ID will be randomly generated, the default name will be the attribute name. After MC 1.21: required 'key' key, and optional 'slot'. The 'key' is the attribute's name/identifier in a "namespace:key" format (defaulting to the "minecraft" namespace), which has to be distinct to other modifiers of the same type on the object. Valid operations: ADD_NUMBER, ADD_SCALAR, and MULTIPLY_SCALAR_1 Valid slots (used up to MC 1.20.6): HAND, OFF_HAND, FEET, LEGS, CHEST, HEAD, ANY Valid slot groups (used on MC 1.20.6+): https://hub.spigotmc.org/javadocs/spigot/org/bukkit/inventory/EquipmentSlotGroup.html Valid attribute names are listed at https://hub.spigotmc.org/javadocs/spigot/org/bukkit/attribute/Attribute.html The default slot/slot group is "any". Operation names are based on the Bukkit enum. ADD_NUMBER corresponds to Mojang "ADDITION" - adds on top of the base value. ADD_SCALAR corresponds to Mojang "MULTIPLY_BASE" - adds to the total, multiplied by the base value. MULTIPLY_SCALAR_1 corresponds to Mojang "MULTIPLY_TOTAL", multiplies the final value (after both "add_number" and "add_scaler") by the amount given plus one. They are combined like (pseudo-code):
See also https://minecraft.wiki/w/Attribute#Modifiers For a quick and dirty in-line input, you can do for example: [generic_max_health=<list[<map[key=my_project:add_health;operation=ADD_NUMBER;amount=20;slot=HEAD]>]>] For more clean/proper input, instead do something like:
When pre-defining a custom item, instead of this, simply use an item script: item script containers. That page shows an example of valid attribute modifiers on an item script. |
| Group | Properties |
| Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/properties/entity/EntityAttributeModifiers.java#L208 |
| 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#L26 |
| Name | Script Syntax |
| Description | The syntax of Denizen is broken into multiple abstraction layers.
At the highest level, Denizen scripts are stored in script files, which use the '.dsc' suffix Denizen script syntax is approximately based on YAML configuration files, and is intended to seem generally as easy to edit as a YAML configuration. However, several key differences exist between the Denizen script syntax and YAML syntax. In particular, there are several changes made to support looser syntax rules and avoid some of the issues that would result from writing code directly into a plain YAML file. Within those 'script files' are 'script containers', which are the actual unit of separating individual 'scripts' apart. (Whereas putting containers across different files results in no actual difference: file and folder separation is purely for your own organization, and doesn't matter to the Denizen parser). Each script container has a 'type' such as 'task' or 'world' that defines how it functions. Within a script container are individual script paths, such as 'script:' in a 'task' script container, or 'on player breaks block:' which might be found within the 'events:' section of a 'world' script container. These paths are the points that might actually be executed at any given time. When a path is executed, a 'script queue' is formed to process the contents of that script path. Within any script path is a list of 'script entries', which are the commands to be executed. These can be raw commands themselves (like 'narrate') with their arguments, or commands that contain additional commands within their entry (as 'if' and 'foreach' for example both do). |
| Group | Denizen Scripting Language |
| Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/objects/core/ScriptTag.java#L54 |
| Name | 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: - sit 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 default or exclusively (for example, "give" defaults to giving items to the linked player but that can be changed with the "to" argument, "sit" exclusively makes the linked NPC sit, 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. You can also modify the linked player or NPC for an entire queue using the fake-definitions '__player' and '__npc', for example: |
| Group | Script Command System |
| Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/implementation/DenizenCoreImplementation.java#L107 |
| Name | <util.list_numbers_to[<#>]> |
| Returns | ListTag |
| Description | Returns a list of integer numbers from 1 to the specified input number (inclusive).
Note that you should NEVER use this as the input to a "foreach" command. Instead, use repeat. In most cases, there's a better way to do what you're trying to accomplish than using this tag. Consider instead using util.list_numbers |
| Generated Example | |
| Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/core/UtilTagBase.java#L298 |
| Name | <util.list_numbers[to=<#>;(from=<#>/{1});(every=<#>/{1})]> |
| Returns | ListTag |
| Description | Returns a list of integer numbers in the specified range.
You must specify at least the 'to' input, you can optionally specify 'from' (default 1), and 'every' (default 1). Note that this generally should not be used as input to the 'foreach' command. Instead, use repeat. |
| Example | |
| Example | |
| Example | |
| Source | https://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/core/UtilTagBase.java#L266 |
| Name | PlayEffect |
| Syntax | playeffect [effect:<name>] [at:<location>|...] (data:<#.#>) (special_data:<map>) (visibility:<#.#>) (quantity:<#>) (offset:<#.#>,<#.#>,<#.#>) (targets:<player>|...) (velocity:<vector>) |
| Short Description | Plays a visible or audible effect at the location. |
| Full Description | Allows the playing of particle effects anywhere without the need of the source it comes from originally.
The particles you may use, can come from sources such as a potion effect or a portal/Enderman with their particles respectively. Some particles have different data which may include different behavior depending on the data. Default data is 0 Specifying a visibility value changes the sight radius of the effect. For example if visibility is 15; Targeted players won't see it unless they are 15 blocks or closer. You can add a quantity value that allow multiple of the same effect played at the same time. If an offset is set, each particle will be played at a different location in the offset area. Everyone will see the particle effects unless a target has been specified. See Particle Effects for a list of valid effect names. Version change note: The original PlayEffect command raised all location inputs 1 block-height upward to avoid effects playing underground when played at eg a player's location. This was found to cause too much confusion, so it is no longer on by default. However, it will still happen for older commands. The distinction is in whether you include the (now expected to use) "at:" prefix on your location argument. If you do not have this prefix, the system will assume your command is older, and will apply the 1-block height offset. Some particles will require input to the "special_data" argument. The data input is a MapTag with different keys per particle. - For DUST particles, the input is of format [size=<size>;color=<color>], e.g. "[size=1.2;color=red]". - For DUST_COLOR_TRANSITION particles, the input is of format [size=<size>;from=<color>;to=<color>], e.g "[size=1.2;from=red;to=blue]". - For BLOCK, BLOCK_CRUMBLE, BLOCK_MARKER, DUST_PILLAR, or FALLING_DUST particles, the input is of format [material=<material>], e.g. [material=stone] - For VIBRATION particles, the input is of format [origin=<location>;destination=<location/entity>;duration=<duration>], for example: [origin=<player.location>;destination=<player.cursor_on>;duration=5s] - For ITEM particles, the input is of format [item=<item>], e.g. "[item=stick]". - For TRAIL particles, the input is of format [color=<color>;target=<location>;duration=<duration>], e.g. "[color=red;target=<player.cursor_on>;duration=20s]". - For ENTITY_EFFECT particles, the input is of format [color=<color>], e.g. "[color=green]". - For SHRIEK particles, the input is of format [duration=<duration>], e.g. "[duration=1m]". - For SCULK_CHARGE particles, the input is of format [radians=<element>], e.g. "[radians=<element[90].to_radians>]". Optionally specify a velocity vector for standard particles to move. Note that this ignores the 'data' input if used. |
| Related Tags | <server.effect_types> Returns a list of all 'effect' types known to the server. (...)
<server.particle_types> Returns a list of all particle effect types known to the server. (...)
|
| Usage Example | |
| Usage Example | |
| Usage Example | |
| Usage Example | |
| Usage Example | |
| Usage Example | |
| Usage Example | |
| Synonyms (Search Aid) | particle |
| Group | world |
| Source | https://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/commands/world/PlayEffectCommand.java#L55 |