Wiki Release: 2026.09.8 · UltimateRaids: 0.12.0 · Documentation branch: 1

Objectives, requirements, rewards and actions#

UltimateRaids uses registries. Core processors are built in, while addons/extensions can register additional IDs through the public API. The configuration format stays the same.

Built-in objectives#

ID	Human use
`NONE`	No active objective; normally combine with wave/automatic stage logic.
`KILL_ENTITIES`	Kill tracked raid entities whose `entity-id` matches the objective target.
`KILL_BOSS`	Kill a tracked boss whose `boss.id` matches the objective target.
`SURVIVE`	Maintain the stage for the configured progress amount/time.
`DEFEND`	Keep a matching tracked raid target alive for the required duration.
`DESTROY`	Break matching blocks, optionally only in a configured objective area.
`REACH_LOCATION`	Reach the objective location/area.
`INTERACT`	Interact with the configured target/location.
`COLLECT`	Pick up a required number of matching normal/custom items.
`CAPTURE`	Hold an objective area with enough active participants.
`ESCORT`	Bring matching tracked raid entities to a destination without losing them.

Detailed design examples are in Stages, waves and objectives.

Built-in access requirements#

Requirements are evaluated before normal admission/queue access.

PERMISSION#

- type: PERMISSION
  permission: server.raids.crypt

Use for ranks, donor access, quest unlock flags or staff-only testing.

LEVEL#

Checks the player's level threshold.

- type: LEVEL
  minimum: 20

ITEM#

Requires an item/provider/amount. Use for keys/tickets or custom-item integrations.

GROUP_SIZE#

Requires a group size. Useful for forcing a minimum party size independent of the general lobby minimum.

RAID_COMPLETED#

Requires previous raid completions:

- type: RAID_COMPLETED
  raid: crypt_normal
  completions: 1

This is useful for progression chains and hard-mode unlocks.

MONEY#

Checks a registered economy provider/balance. Normally used with Vault-compatible economy integration.

If an economy/item/group provider is unavailable, validation/debug output should be fixed before opening the raid.

Built-in rewards#

COMMAND#

Runs a console command. Supports context replacements such as player/UUID/raid/instance values exposed by the reward implementation.

ITEM#

Gives an item resolved through DEFAULT or a registered item provider. Overflow behavior follows Core reward configuration.

EXPERIENCE#

Gives raw experience points.

MESSAGE#

Sends a MiniMessage-formatted reward message to the player.

MONEY#

Deposits currency through the selected economy provider.

MONEY_PENALTY#

Withdraws currency. This is useful for failure/penalty sections rather than normal positive rewards.

LOOT_TABLE#

Runs a reusable table from loot/<id>.yml. Loot processing has recursion-depth protection so accidentally recursive tables cannot expand forever.

Reward sections#

A raid reward plan can contain different sections for different outcomes, such as overall completion/failure/participation/first-clear or score-based ranking flows supported by the result manager/configuration.

Keep rewards understandable: use direct rewards for guaranteed essentials and loot tables for randomized pools.

Built-in actions#

Actions are used at raid/stage/boss lifecycle points and inside reusable skills.

MESSAGE
ACTIONBAR
TITLE
SOUND
PARTICLE
COMMAND
TELEPORT
SKILL
ENTITY_SKILL

A reusable skill is essentially a named list of actions stored under skills/.

Example reusable feedback skill#

id: stage_clear
name: '<success>Stage Clear</success>'
actions:
  - type: PARTICLE
    target: PARTICIPANTS
    location: TARGET
    particle: HAPPY_VILLAGER
    amount: 20
  - type: SOUND
    target: PARTICIPANTS
    sound: 'ENTITY_EXPERIENCE_ORB_PICKUP:0.8:1.2'
  - type: ACTIONBAR
    target: PARTICIPANTS
    message: '<success>Stage clear.</success>'

Then call it from stage actions:

- type: SKILL
  skill: stage_clear

Custom processors from addons/extensions#

The public registry API can add custom:

objectives;
requirements;
rewards;
actions.

Once registered, the custom ID is configured using the same general model. TicketAI technical references contain the provider/registry contract; the public Wiki only documents a third-party processor as available when the integration is actually supplied/documented.