Denizen Script Meta Documentation Search


Learn about how Denizen works in The Beginner's Guide.
Showing 8 search results for foreach out of 3939 meta-documentation entries...

Perfect Name Match Results



Command


NameForeach
Related Guide Pagehttps://guide.denizenscript.com/guides/basics/loops.html
Syntaxforeach [stop/next/<object>|...] (as:<name>) (key:<name>) [<commands>]
Short DescriptionLoops through a ListTag, running a set of commands for each item.
Full DescriptionLoops 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 Command:wait or Language:~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 Command: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
# Use to run commands 'for each entry' in a manually created list of objects/elements.
- foreach <[some_entity]>|<[some_npc]>|<[player]> as:entity:
    - announce "There's something at <[entity].location>!"
Usage Example
# Use to iterate through entries in any tag that returns a list.
- foreach <player.location.find_entities[zombie].within[50]> as:zombie:
    - narrate "There's a zombie <[zombie].location.distance[<player.location>].round> blocks away"
Usage Example
# Use to iterate through a list of players and run commands automatically linked to each player in that list.
- foreach <server.online_players> as:__player:
    - narrate "Thanks for coming to our server, <player.name>! Here's a bonus $50.00!"
    - money give quantity:50
Groupqueue
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/scripts/commands/queue/ForeachCommand.java#L31

Semi-Decent Match Results



Language


NameAttribute Modifiers
DescriptionIn 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 Tag:EntityTag.attribute_modifiers, Tag:ItemTag.attribute_modifiers,
Tag:EntityTag.has_attribute, Tag:EntityTag.attribute_value, Tag:EntityTag.attribute_base_value, Tag:EntityTag.attribute_default_value, ...

These can be modified by such mechanisms as Mechanism:EntityTag.attribute_base_values, Mechanism:EntityTag.attribute_modifiers, Mechanism:EntityTag.add_attribute_modifiers,
Mechanism:EntityTag.remove_attribute_modifiers, Mechanism:ItemTag.attribute_modifiers, Mechanism:ItemTag.add_attribute_modifiers, Mechanism: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):

- define x <[base_value]>
- foreach <all_modifiers[ADD_NUMBER]>:
    - define x:+:<[value]>
- define y <[x]>
- foreach <all_modifiers[ADD_SCALAR]>:
    - define y:+:<[x].mul[<[value]>]>
- foreach <all_modifiers[MULTIPLY_SCALAR_1]>:
    - define y:*:<[value].add[1]>
- determine <[y]>


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:

- definemap attributes:
    generic_max_health:
        1:
            key: my_project:add_health
            operation: ADD_NUMBER
            amount: 20
            slot: head
- inventory adjust slot:head add_attribute_modifiers:<[attributes]>


When pre-defining a custom item, instead of this, simply use an item script: Language:item script containers. That page shows an example of valid attribute modifiers on an item script.
GroupProperties
Sourcehttps://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/objects/properties/entity/EntityAttributeModifiers.java#L208
NameInventory Script Containers
DescriptionInventory 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.


# The name of the script is the same name that you can use to construct a new
# InventoryTag based on this inventory script. For example, an inventory script named 'Super_Cool_Inventory'
# can be referred to as 'Super_Cool_Inventory'.
Inventory_Script_Name:

    type: inventory

    # Must be a valid inventory type.
    # Valid inventory types: ANVIL, BREWING, CHEST, DISPENSER, ENCHANTING, ENDER_CHEST, HOPPER, WORKBENCH
    # | All inventory scripts MUST have this key!
    inventory: inventory type

    # The title can be anything you wish. Use color tags to make colored titles.
    # Note that titles only work for some inventory types, including ANVIL, CHEST, DISPENSER, FURNACE, ENCHANTING, HOPPER, WORKBENCH
    # | MOST inventory scripts should have this key!
    title: custom title

    # The size must be a multiple of 9. It is recommended to not go above 54, as it will not show correctly when a player looks into it.
    # | Some inventory scripts should have this key! Most can exclude it if 'slots' is used.
    size: 27

    # Set 'gui' to 'true' to indicate that the inventory is a GUI, meaning it's a set of buttons to be clicked, not a container of items.
    # This will prevent players from taking items out of or putting items into the inventory.
    # | SOME inventory scripts should have this key!
    gui: true

    # You can use definitions to define items to use in the slots. These are not like normal script definitions, and do not need to be in a definition tag.
    # | Some inventory scripts MAY have this key, but it is optional. Most scripts will just specify items directly.
    definitions:
        my item: ItemTag
        other item: ItemTag

    # Procedural items can be used to specify a list of ItemTags for the empty slots to be filled with.
    # Each item in the list represents the next available empty slot.
    # When the inventory has no more empty slots, it will discard any remaining items in the list.
    # A slot is considered empty when it has no value specified in the slots section.
    # If the slot is filled with air, it will no longer count as being empty.
    # | Most inventory scripts should exclude this key, but it may be useful in some cases.
    procedural items:
    - define list <list>
    - foreach <server.online_players>:
        # Insert some form of complex doesn't-fit-in-just-a-tag logic here
        - define item <[value].skull_item>
        - define list:->:<[item]>
    - determine <[list]>

    # You can specify the items in the slots of the inventory. For empty spaces, simply put an empty "slot" value, like "[]".
    # | Most inventory scripts SHOULD have this key!
    slots:
    - [] [] [] [my item] [ItemTag] [] [other item] [] []
    - [my item] [] [] [] [] [ItemTag] [ItemTag] [] []
    - [] [] [] [] [] [] [] [] [other item]
GroupScript Container System
Sourcehttps://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/containers/core/InventoryScriptContainer.java#L26
NameScript Syntax
DescriptionThe syntax of Denizen is broken into multiple abstraction layers.

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

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

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

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

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

- foreach <server.players> as:__player:
    - narrate "Hi <player.name> isn't it nice how the player is linked here"
GroupScript Command System
Sourcehttps://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/utilities/implementation/DenizenCoreImplementation.java#L107

Tag


Name<util.list_numbers_to[<#>]>
ReturnsListTag
DescriptionReturns 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 Command:repeat.
In most cases, there's a better way to do what you're trying to accomplish than using this tag.
Consider instead using Tag:util.list_numbers
Generated Example
- foreach <util.list_numbers_to[4]> as:entry:
    - narrate "found <[entry]>"
Sourcehttps://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})]>
ReturnsListTag
DescriptionReturns 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 Command:repeat.
Example
# Narrates "1, 2, and 3"
- narrate <util.list_numbers[to=3].formatted>
Example
# Narrates "3, 4, and 5"
- narrate <util.list_numbers[from=3;to=5].formatted>
Example
# Narrates "4, 8, and 12"
- narrate <util.list_numbers[from=4;to=12;every=4].formatted>
Sourcehttps://github.com/DenizenScript/Denizen-Core/blob/master/src/main/java/com/denizenscript/denizencore/tags/core/UtilTagBase.java#L266

Just Barely Matched Results



Command


NamePlayEffect
Syntaxplayeffect [effect:<name>] [at:<location>|...] (data:<#.#>) (special_data:<map>) (visibility:<#.#>) (quantity:<#>) (offset:<#.#>,<#.#>,<#.#>) (targets:<player>|...) (velocity:<vector>)
Short DescriptionPlays a visible or audible effect at the location.
Full DescriptionAllows 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 Language: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
# Use to create a fake explosion.
- playeffect effect:EXPLOSION_HUGE at:<player.location> visibility:500 quantity:10 offset:2.0
Usage Example
# Use to play a cloud effect.
- playeffect effect:CLOUD at:<player.location.add[0,5,0]> quantity:20 data:1 offset:0.0
Usage Example
# Use to play some effects at spawn.
- playeffect effect:FIREWORKS_SPARK at:<world[world].spawn_location> visibility:100 quantity:375 data:0 offset:50.0
Usage Example
# Use to spawn a cloud of rainbow-colored ENTITY_EFFECT particles around yourself.
- foreach <util.color_names> as:color:
    - playeffect effect:ENTITY_EFFECT at:<player.eye_location> quantity:25 special_data:[color=<[color]>]
Usage Example
# Use to shoot particles in to the direction you're looking at.
- repeat 10:
    - playeffect effect:TRAIL at:<player.eye_location> quantity:1 offset:0 special_data:[color=red;target=<player.eye_location.ray_trace[default=air]>;duration=5s]
    - wait 1t
Usage Example
# Use to spawn a SCULK_CHARGE effect upside down.
- playeffect effect:SCULK_CHARGE at:<player.eye_location.add[0,1,0]> quantity:1 offset:0 special_data:[radians=<element[180].to_radians>]
Usage Example
# Use to play a SHRIEK effect with a 5-second delay.
- playeffect effect:SHRIEK at:<player.eye_location.add[0,1,0]> quantity:1 special_data:[duration=5s]
Synonyms (Search Aid)particle
Groupworld
Sourcehttps://github.com/DenizenScript/Denizen/blob/dev/plugin/src/main/java/com/denizenscript/denizen/scripts/commands/world/PlayEffectCommand.java#L55