Casting Skills
A casting skill is an attack pattern where a mob casts a skill registered in AstralSkill. The cast-skill AI goal is the only mechanism by which an AstralMobs blueprint triggers AstralSkill skills.
Every cast-skill goal instance casts a single skill on each tick it's active, holding position at a configured preferred-range from the target. The skill is cast from the mob's eye position through the target's eye position, allowing line-of-sight projectiles and area effects. AstralSkill is a soft dependency — if it is absent or not yet initialized, casts silently no-op and the kiting still works.
Configuration
A cast-skill goal in goal-selectors inherits all fields from KiteGoal plus two of its own:
Field | Type | Required | Description |
|---|---|---|---|
| String | Yes | Id of a skill registered in AstralSkill. If the skill does not exist in AstralSkill's registry when the cast fires, the cast fails silently. |
| boolean | No, default | When |
| double | No, default | Distance in blocks the mob tries to maintain from the target while kiting. |
| double | No, default | Half-width of the dead band around |
| double | No, default | Movement speed multiplier while repositioning to or holding the preferred range. |
| int | No, default | Goal priority — higher numbers = lower priority (runs only if no higher-priority goal is active). |
| List | No, default | Movement control flags (e.g., |
| Requirements list | No | Gating conditions (e.g., cooldown timers, memory counters) that must pass before the goal activates. See Requirements & Actions. |
| Requirements list | No | Conditions checked every tick; when any fails, the goal stops immediately. |
| boolean | No, default | If |
| Actions list | No | Fired once when the goal starts (e.g., start-timer, store-memory, send-entity-status). See Requirements & Actions. |
| Actions list | No | Fired once when the goal stops. |
| Actions list | No | Fired when |
| boolean | No, default | If |
| boolean | No, default | If |
Inherited from KiteGoal
All cast-skill goals inherit from KiteGoal, which inherits from AstralGoal. Casting is purely overlaid on top of the kiting mechanics — every tick, the parent KiteGoal.tick() runs first (repositioning the mob and facing the target), then cast() casts the skill and stops the goal.
Minimal example
Casting Mechanics
Tick-by-tick behavior
On each tick the goal is active:
Kite — move toward/away from the target to maintain
preferred-range, face the target, and hold position inside the tolerance band. This is inherited fromKiteGoal.Cast — if AstralSkill is loaded and initialized:
Get the skill by id from
SkillAPI.service().Call
SkillService.castThroughPos(mob, mob.getUUID(), skill-id, mob-eye-location, target-eye-location, container, force-cast).Register the
mobplaceholder (accessible to the skill as%mob%).Stop the goal (single cast per activation cycle).
If AstralSkill is absent or not yet initialized, the cast is skipped and the goal continues to hold position (kiting still works).
Line of sight and reachability
By default, SkillService.castThroughPos checks whether the target is reachable (navigable path exists) and in line of sight. When force-cast: true, these checks are bypassed, allowing the mob to cast at unreachable or obstructed targets (e.g., through walls, across chasms).
Placeholder registration
When a skill is cast, the mob placeholder is registered in the skill's execution context, making the mob entity available to the skill's triggers, selectors, and actions. See Placeholders for the full list.
Soft Dependency on AstralSkill
CastSkillGoal checks two conditions before casting:
When either check fails (plugin absent or not initialized), skillService() returns null, and the cast is skipped silently on every tick. The kiting still works — the mob maintains distance and faces the target, but no skill fires. Once AstralSkill is loaded and initialized (or on the next reload), casts resume automatically.
The Charge → Fire Pattern
Real bosses use a two-phase attack: a high-priority warning/charge cast-skill goal that starts timers, followed by a lower-priority actual-attack goal that fires inside the timer window. The warning phase has can-continue-to-use-also-can-use: false so it runs to completion even if the target moves out of range; the actual phase gates itself with %mob_timer_*% and %mob_memory_*% compare requirements.
Why two separate goals?
Separation of concerns — wind-up animation/particles are separate from the projectile cast, each with its own skill.
Timing precision — timer checks ensure the projectile fires at the exact frame the server and client visual windup align.
Stall prevention — if a target moves out of range during the charge, the actual-attack goal can still fire if the timer window is open.
Structure
In this pattern:
The warning goal has
priority: 3and no requirement gates, so it activates immediately.It starts a timer
cooldown-cast-laserand sets a flagshot-laser 0.The actual goal has
priority: 2(lower = runs only if warning is not active).It gates itself with
2000 < timer < 2999, ensuring the projectile fires exactly 2-3 seconds after the warning started.After firing, it sets the flag to
1, preventing the actual goal from firing again until the warning resets the flag to0.
Worked Example: Evoker Boss
The evoker-boss blueprint demonstrates a complex multi-attack pattern: two simultaneous charge → fire cycles (laser and spread attack) plus a fallback basic cast:
How it plays:
On spawn,
cooldown-cast-goalstarts (global spacing timer).Laser warning (priority 3) fires first, resets the global timer to 6s, starts its own laser timer.
Spread warning (priority 5) fires when its own 4s window opens, resets global timer.
Laser actual (priority 2) fires 2-3s after laser warning, increments shot counter, fires up to 2 shots.
Spread actual (priority 4) fires 2-3s after spread warning, up to 4 shots.
Fallback basic cast (priorities 1 & 0) fires only when both laser and spread are cooling down.
Interplay with Actions & Timers
start-actions and stop-actions orchestrate the visual sync between the mob's pose, animation state, and the skill execution:
Common action patterns:
[start-timer] name— starts a timer namednameat 0 ms, incremented each tick. Used as gates in requirements.[store-memory] key value— stores a numeric value in mob memory (per-entity). Use$e(...)math expressions to increment/compute values.[send-entity-status] code— sends an entity-status packet (e.g.,62= Warden's sonic-boom charge).[edit-entity-metadata] index type value— edits metadata to pose/animation states (e.g.,ENTITY_POSE STANDING).
See Mob Actions for the full action reference and Placeholders for timer and memory placeholder syntax (%mob_timer_*%, %mob_memory_*%).
Requirements & Actions
Both can-use-requirements and can-continue-requirements accept a list of requirement expressions (e.g., [compare] gates on timer/memory values). The min-requirements field gates whether ALL (AND) or ANY (OR) requirements must pass:
min-requirements: 1→ Fire if ANY requirement is true (OR logic)min-requirements: 2→ Fire if ANY 2+ requirements are truemin-requirements: 3→ Fire if ALL 3 requirements are true (AND logic when == number of requirements)Omitted → Fire if ANY requirement is true (default
1)
See AI Goals, Targeting & Movement for the shared can-use-requirements/can-continue-requirements fields.
Cross-Reference: AstralSkill Skills
Skill ids referenced in the skill: field must exist in AstralSkill's registry. A skill file defines:
Cast type — how the skill is cast and resolved (
dummy,projectile,laser,impact,auto_cast,n_cast)Targeting — who/what the skill affects (caster, target, area) via relationship and selection rules
Behavior — cast/target effects, damage, status effects, and custom actions
AstralMobs does not define or configure skills; it only references them by id via CastSkillGoal, which casts through SkillService.castThroughPos. To add or modify a skill, edit the AstralSkill skill files and reload/restart the server.
See the AstralSkill documentation for:
Overview — skill types and the casting engine
Cast Types — how skills reach and affect targets
Targeting — relationship rules and target/impact selection
Skill Files — the skill YAML structure
cast-skillgoals reference by id