Skip to main content

Elite Script Targets

Targets select the entities or locations used by actions, conditions and zones. Write Target as a YAML mapping. targetType defaults to SELF, range to 20.0, and track to true. Target field names are case-insensitive; target-type enum values must be uppercase.

Target Types​

Target types set what entities or locations get targeted by a script.

DIRECT_TARGET is the event's entity: it can be an attacking elite or an entity crossing a zone, as well as a player. Use it only with a compatible event; without a direct target it selects nothing. It is not automatically the boss's current combat target. Nearby target types scan an axis-aligned box around the boss and do not sort by distance.

Entity targets can supply their current feet locations to location actions. The reverse is not automatic: LOCATION, LOCATIONS and LANDING_LOCATION cannot select entities occupying those positions. Create a zone there to find entities. Player selectors do not themselves exclude spectators or players in other encounters; an action may apply additional eligibility rules.

Target TypeDetailsSpecial
NEARBY_PLAYERSPlayers in rangeOptional range, default 20.0
NEARBY_MOBSNon-player living entities in range, excluding the bossOptional range, default 20.0
NEARBY_ELITESTracked elites in range, excluding the bossOptional range, default 20.0
WORLD_PLAYERSPlayers in world❌
ALL_PLAYERSPlayers in the server❌
DIRECT_TARGETThe entity supplied by the eventRequires a compatible event
SELFElite using power❌
SELF_SPAWNThe boss's stored spawn location for location actionsEntity actions still receive the boss itself
LOCATIONSpecific locationRequires location
LOCATIONSSeveral specific locationsRequires locations
ZONE_FULLTargets inside of zoneRequires Zone
ZONE_BORDERTargets border of zoneRequires Zone
ACTION_TARGETUses the surrounding action's target contextOnly for action conditions with FILTERING, and Relative Vectors; not a standalone action target
LANDING_LOCATIONTargets the location a block or entity landed on.Can only be used in the landingScripts of the SPAWN_FALLING_BLOCK and SUMMON_ENTITY actions!
INHERIT_SCRIPT_TARGETInherits the target from the script that runs this scriptCan only run if the script was called by another script!
INHERIT_SCRIPT_ZONE_FULLTargets inside of zone inherited from the script that runs this scriptRequires Zone in the script that calls this script!
INHERIT_SCRIPT_ZONE_BORDERTargets border of zone inherited from the script that runs this scriptRequires Zone in the script that calls this script!
Example
eliteScript:
Example:
Events:
- EliteMobDeathEvent
Actions:
- action: MESSAGE
Target:
targetType: ALL_PLAYERS
sValue: "&2Hello World!"

This sends a message to the target. Since the target is set to ALL_PLAYERS, it will send that message to all online players.


Shared attributes​

The following settings apply when resolving target locations. They do not move an entity or change which entity receives an action.

ValuesDetailsSpecial
offsetSets the offset for the target location.Can't target entities!
relativeOffsetOffsets target locations using a relative vector blueprint. Its source and destination targets determine direction.Can't target entities!

Offsets apply to locations resolved from entity targets such as SELF and DIRECT_TARGET, to SELF_SPAWN, LOCATION and LOCATIONS, and to each location sampled from a zone by ZONE_FULL, ZONE_BORDER and their inherited variants. To move the whole zone, put the offset on the zone's own Target instead, as in the examples below. The same rules apply through Lua script utilities.

offset uses world X/Y/Z coordinates, not the entity's facing direction. It is applied before relativeOffset. LANDING_LOCATION and INHERIT_SCRIPT_TARGET results bypass these added offsets. Inside a relative vector, ACTION_TARGET uses its supplied action location directly and ignores its own offset settings.

Example
eliteScript:
Example:
Events:
- EliteMobDeathEvent
Actions:
- action: STRIKE_LIGHTNING
Target:
targetType: SELF
offset: "0,2,0"

This strikes lightning 2 blocks above the boss. STRIKE_LIGHTNING selects locations, so its target accepts an offset. The strike is visual only and does not damage entities.

You can't set an offset to send a message, since messages are sent to players. You can, however, set an offset to a zone that can then target entities.


range​

Sets the half-width of the search box for NEARBY_PLAYERS, NEARBY_MOBS, and NEARBY_ELITES. The same value is used on the X, Y, and Z axes; this is not a spherical distance cutoff. The mob and elite queries exclude the casting boss.

Use a fixed nonnegative number for a consistent box. A ~ range can be sampled separately for each axis and uses the floating-point sampler described under coverage below; it does not guarantee a cube with a single sampled radius.

ValuesDetailsDefault
rangeHalf-width in blocks for nearby player, mob and elite queries.20.0
Example
eliteScript:
Example:
Events:
- EliteMobDeathEvent
Actions:
- action: MESSAGE
Target:
targetType: NEARBY_PLAYERS
range: 25.0
sValue: "&2Targeted players within 25 blocks!"

This sends a message to players in the box extending 25 blocks along each axis from the boss when it dies.

location​

Sets the location for the LOCATION target type.

ValuesDetailsDefault
locationSets the world location that will be targeted.none

This uses the format location: worldname,x,y,z,yaw,pitch for the location. worldname,x,y,z is also accepted (yaw and pitch then default to 0), as is the world-less x,y,z,yaw,pitch, though that last form leaves the location without a world and is rarely what you want. A bare three-value x,y,z is not valid and is rejected with Attempted to deserialize an invalid location! in the console.

Use a loaded world or same_as_boss. Parsing does not load a world, and malformed input or an unresolved world can fail when the target is used. Coordinates are absolute, including when using same_as_boss; that placeholder changes only the world.

When the configured world is not loaded and the boss is in a world named <configuredWorld>_<number>, the target resolves to that instance world. This fallback does not override a configured world that is already loaded.

Note that same_as_boss is a valid placeholder for the world name, such as same_as_boss,100,64,100,0,0 would be a valid location that would target the same world as where the boss is.

Example
eliteScript:
Example:
Events:
- EliteMobDeathEvent
Actions:
- action: STRIKE_LIGHTNING
Target:
targetType: LOCATION
location: "myWorld,100,64,200,0,0"

This spawns a lighting strike at the location x=100, y=64, z=200 of a world called myWorld.


locations​

Sets the locations for the LOCATIONS target type.

ValuesDetailsDefault
locationsSets the list of world locations that will be targeted.none

This uses the format worldname,x,y,z,yaw,pitch for each location, with the same accepted variants as location.

Note that same_as_boss is a valid placeholder for the world name, such as same_as_boss,100,64,100,0,0 would be a valid location that would target the same world as where the boss is.

Example
eliteScript:
Example:
Events:
- EliteMobDeathEvent
Actions:
- action: STRIKE_LIGHTNING
Target:
targetType: LOCATIONS
locations:
- "myWorld,100,64,200,0,0"
- "same_as_boss,-100,12,130,0,0"

This spawns a lighting strike at the location x=100, y=64, z=200 of a world called myWorld and another lighting strike in the same world as the boss at the location x=-100, y=12 and z=130.


Targeting zones​

Zones separate their origin targets from the actions that use their geometry. Zone.Target supplies origins; an action's ZONE_FULL or ZONE_BORDER target selects from the resulting shapes. Multiple origin locations can generate multiple shapes. Entity results are deduplicated; overlapping shapes can still contribute duplicate particle locations.

Zones work in two parts:

Part 1 - Setting where the zone goes​

Zones need to know where they are supposed to be, and to do that you use the target system the same way you would for any other location-based effect, like a lightning strike.

Example
eliteScript:
VisualCylinder:
Events:
- EliteMobDamagedEvent
Zone:
radius: 10.0
shape: CYLINDER
height: 1
filter: PLAYER
borderRadius: 5.0
Target:
targetType: SELF

This illustrates a cylinder of radius 10 and height 1, starting at the boss's feet and extending upward. It has no actions yet and is only a fragment; a runnable script needs the Actions shown below. filter: PLAYER applies to entity queries, not the geometric locations used for particles.

Some zones, like STATIC_RAY, have two or more targets. This is because rays are lines, and lines are defined by two points. This is covered more extensively in the zones page, but they fundamentally all work the same way.

Part 2 - Targeting the inside of the zone​

Use targetType: ZONE_FULL for the full shape or targetType: ZONE_BORDER for its border. Location actions receive sampled geometric positions; entity actions receive matching entities according to the zone's filter and containment checks. They do not receive the same kind of collection.

Example
eliteScript:
VisualCylinder:
Events:
- EliteMobDamagedEvent
Zone:
radius: 10.0
shape: CYLINDER
height: 1
filter: PLAYER
borderRadius: 5.0
Target:
targetType: SELF
Actions:
- action: SPAWN_PARTICLE
times: 12
repeatEvery: 5
particles:
- particle: SMOKE_NORMAL
Target:
targetType: ZONE_FULL

This adds particles at sampled positions throughout the cylinder, rather than at player positions. There are 12 executions spaced 5 ticks apart. Zone particle actions default to approximately 30% coverage unless coverage is explicitly set. filter: PLAYER does not restrict these particles to players.

Note that ZONE_BORDER is not available for every zone. More on that in the script zones page.

Zone track​

Set track on the action's Target, as shown below. With true, zone shapes normally resolve moving origins again when requested. With false, that action caches zone shapes before its wait, keeping the origin fixed while later entity queries still find entities currently inside the cached shape. It does not freeze the players present at cast time.

ValuesDetailsDefault
trackRe-resolve the action target instead of caching its zone origin and sampled locations.true

With a positive animationDuration, the action caches the animated shapes when it starts, whatever its track setting. It caches the shapes, not a static list of their positions, so their animation continues. More on that here.

Example
eliteScript:
VisualCylinder:
Events:
- EliteMobDamagedEvent
Zone:
radius: 10.0
shape: CYLINDER
height: 1
filter: PLAYER
borderRadius: 5.0
Target:
targetType: SELF
Actions:
- action: SPAWN_PARTICLE
times: 12
repeatEvery: 5
particles:
- particle: SMOKE_NORMAL
Target:
targetType: ZONE_FULL
track: false

Using the same example from part 1 and part 2, the zone is now set to not track. This means that the zone will spawn at the boss location, but even as the boss keeps moving away, the zone will stay where it first spawned.

The cache is prepared when the action is started, before that action's wait. Delaying RUN_SCRIPT delays the start and therefore the cache of the called script as well.

For a warning followed by damage at the original position, start both scripts immediately and put wait on the damage actions. Use matching fixed origins if the positions must remain identical regardless of movement or earlier actions.

The following is a correct example of a power with a warning and a damage phase taken from the Frost Palace Sanctum.

Example
eliteScript:
VisualCylinder:
Events:
- EliteMobDamagedEvent
Zone:
radius: 10.0
shape: CYLINDER
height: 1
filter: PLAYER
borderRadius: 5.0
Target:
targetType: SELF
Actions:
- action: SPAWN_PARTICLE
times: 12
repeatEvery: 5
particles:
- particle: SMOKE_NORMAL
Target:
targetType: ZONE_FULL
track: false
- action: SPAWN_PARTICLE
wait: 60
times: 13
repeatEvery: 3
particles:
- particle: FLAME
amount: 0
x: 0
y: 1
z: 0
speed: 0.2
- particle: FLAME
amount: 0
x: 0.5
y: 1
z: 0.5
speed: 0.2
- particle: FLAME
amount: 0
x: 0
y: 1
z: 0.5
speed: 0.2
- particle: FLAME
amount: 0
x: 0.5
y: 1
z: 0
speed: 0.2
- particle: FLAME
amount: 0
x: -0.5
y: 1
z: -0.5
speed: 0.2
- particle: FLAME
amount: 0
x: -0.5
y: 1
z: 0
speed: 0.2
- particle: FLAME
amount: 0
x: 0
y: 1
z: -0.5
speed: 0.2
- particle: FLAME
amount: 0
x: -0.5
y: 1
z: 0.5
speed: 0.2
- particle: FLAME
amount: 0
x: 0.5
y: 1
z: -0.5
speed: 0.2
Target:
targetType: ZONE_FULL
track: false
- action: RUN_SCRIPT
scripts:
- DamageCylinder
- action: PLAY_ANIMATION
sValue: fire_zone
Target:
targetType: SELF
- action: SET_MOB_AI
duration: 100
bValue: false
Target:
targetType: SELF
Cooldowns:
local: 1200
global: 300
DamageCylinder:
Zone:
radius: 10.0
shape: CYLINDER
height: 10
filter: PLAYER
borderRadius: 5.0
Target:
targetType: SELF
offset: 0,-1,0
Actions:
- action: DAMAGE
wait: 60
repeatEvery: 10
times: 4
multiplier: 4
Target:
targetType: ZONE_FULL
track: false
- action: SET_ON_FIRE
wait: 60
duration: 80
Target:
targetType: ZONE_FULL
track: false

This script does a lot of things, but it is separated into two clear scripts: VisualCylinder and DamageCylinder.

VisualCylinder runs first and has the RUN_SCRIPT action which immediately also runs the DamageCylinder at the same time the VisualCylinder is running.

However, every single action in DamageCylinder is set to wait for 60 ticks, or 3 seconds.

The warning lasts 3 seconds before the delayed effects start. Both scripts capture the same horizontal boss position when started immediately. Their volumes differ: the visual cylinder has height 1 at the feet, while the damage cylinder starts 1 block lower and has height 10. DAMAGE repeats four times at 10-tick intervals; SET_ON_FIRE runs once after the wait and requests 80 fire ticks. The animation needs a compatible custom model with fire_zone.

Each run of an action keeps its own cache. Overlapping casts of the same script do not overwrite each other's cached locations, and a new cast never reuses locations cached by an earlier one.

Zone-specific target properties​

Zone have the following specific properties:

coverage​

Sets the percentage of the zone that will actually be used for the action. Only works for location targets (won't work when targetting players or other entities).

ValuesDetailsDefault
coverageFraction of zone locations to retain, such as 0.5 for approximately half. Prefer a fixed value from 0 to 1.1.0

A range such as 0.3~1.0 samples a value from 0.3 up to, but not including, 1.0, and coverage can be sampled separately for individual points. Use a fixed fraction for predictable coverage. An explicit coverage: 1.0 keeps all sampled positions; omitted coverage on a zone SPAWN_PARTICLE action defaults to 0.3. Coverage does not reduce entity queries. With track: false, a static zone's sampled location selection is cached and reused rather than rerolled for every repeat.

Example
eliteScript:
VisualCylinder:
Events:
- EliteMobDamagedEvent
Zone:
radius: 10.0
shape: CYLINDER
height: 1
filter: PLAYER
borderRadius: 5.0
Target:
targetType: SELF
Actions:
- action: SPAWN_PARTICLE
times: 12
repeatEvery: 5
particles:
- particle: SMOKE_NORMAL
Target:
targetType: ZONE_FULL
track: false
coverage: 0.5

In this case, each sampled location has a 50% chance of being retained for particles. The resulting count is approximate, not exactly half.

Inheriting targets​

When a script runs another script (or "calls" that script), it is possible to pass zone and target information from the first script to the second.

Example uses

  1. Improved script runners

Script runners are scripts whose only function is to run a lot of other scripts. They are used to make managing scripts easier, especially when handling several scripts that require precise timing.

With target inheritance, several scripts can use the same zone or target, cutting down potentially hundreds of lines of repetitive scripting.

  1. Matryoshka target filtering / Russian nesting doll target filtering

A parent action that actually resolves and filters entity targets can pass its cached result to a child through its scripts list. Keep parent and child target kinds compatible. RUN_SCRIPT itself does not run the per-target filtering path, so adding a FILTERING condition to it does not produce a filtered list for inheritance.

Use ACTION_TARGET with FILTERING on the entity action for tag checks. A random chance requires script-level or BLOCKING conditions; it is not a per-entity filtering roll. isAlive checks Bukkit validity, so reversing it is not a dependable way to trigger behavior on a player's death.

  1. Complex zones

Finally, it is possible to layer targets to create complex zones, optionally using conditions if required, and it is even possible to create semi-randomized zones using the script conditions and the ability to only run one of the listed scripts from the script actions.

Note: For this section, "parent script" refers to the script that runs the "inheriting script", which is the script which will be using the inherited targets.

When using target inheritance, it is important to take a careful look at the parent script to make sure the correct data is getting passed down.

INHERIT_SCRIPT_TARGET​

INHERIT_SCRIPT_TARGET reads the target resolver or cache of the specific parent action that called the child, not the union of all targets in the parent script. Put it on the child's actions or zone origins, not its top-level Conditions: those are evaluated before inherited action data is available, and the inherited target fails there with an error.

The parent passes its resolved, condition-filtered targets only when its Target has track: false. With the default track: true, the child resolves the parent's target again, without the parent's filtering. A RUN_SCRIPT parent never resolves its own targets, so its child always resolves entities again. With track: false, the child does reuse the locations that parent cached when its action started. This has a couple of caveats:

  • When passing entity targets, the child can use them with entity actions or with location actions. Location actions receive the entities' locations.

  • When passing location targets, is it only possible to use locations. An entity action that inherits locations fails with an error. The only way to get an entity from a locations is by creating a zone at that location and looking for entities. So, while it is not impossible to pass a location and then get entities, it will require a little bit of extra work.

Inheriting zones​

When using INHERIT_SCRIPT_ZONE_FULL or INHERIT_SCRIPT_ZONE_BORDER, it is imperative that the parent script defines a zone, or else the inheriting script will not be able to run correctly.

An action with track: false caches its zone shapes before its wait begins. A tracked action normally leaves them uncached and resolves moving origins again. Passing parent action data can reuse cached shapes; setting track: true does not freeze a shared location.

Inherited zone targets use the parent script's own Zone and the shapes cached by the calling action, if it cached any. INHERIT_SCRIPT_ZONE_FULL entity queries use the full-volume test, like ZONE_FULL. If the parent script has no valid zone, or the script was not called by another script, the action fails with an error.

To share a fixed origin, give the calling action's Target track: false. The child then reuses the shapes the parent cached when its action started, even if the child's own actions wait.