Combat And Prayer Actions

Verification boundary

revision-sensitive RuneLite UI, packet, or in-game outcomes; treat those as live-client verification pending unless the page records direct evidence.

Caution

Prayer convergence succeeded, but the returned metadata identified the wrong prayer and typed quick-prayer opening failed to resolve the visible Setup widget. Combat-style behavior remains live-client verification pending. Check the resulting widget state, not only the action result.

CombatActions and PrayerActions provide result-aware writes for combat settings and prayers. Every method below returns InteractionResult. Combat settings, individual prayer toggles, quick-prayer opening, and orb toggling use the shared action path and can return PACED without queuing a packet.

Attack-style and auto-retaliate changes require the Combat tab to be visible. Prayer changes require the Prayer tab only when the observed state still differs. A missing prerequisite returns WIDGET_HIDDEN targeting the required tab, queues no dependent action, and never selects the tab. The special-attack and quick-prayer orb operations keep their existing tab-independent behavior.

For health, poison, wilderness, combat-session, prayer-point, and active-prayer reads, use the state reads on CombatActions and PrayerActions described on this page. For target discovery, use Query Helpers, then dispatch the attack through NPCActions.interact(...).

Combat Settings

Method	Behavior
`CombatActions.toggleSpec()`	Clicks the visible special-attack orb; returns `COMBAT_SPEC_UNAVAILABLE` when the orb is unavailable.
`CombatActions.setAttackStyle(AttackStyle)`	Clicks the combat-tab button mapped to the requested style.
`CombatActions.toggleAutoRetaliate(boolean)`	Idempotently converges auto-retaliate to the requested state.

InteractionResult result = CombatActions.toggleAutoRetaliate(true);
if (result.failed() && result.getStatus() != InteractionStatus.PACED) {
    log.debug("Auto-retaliate update failed: {}", result.getMessage());
}

setAttackStyle(null) returns TARGET_NULL. A missing or hidden combat-style or auto-retaliate component returns WIDGET_NOT_FOUND. These widget mappings respond to revision changes and require live-client verification after a RuneLite revision change.

Prayer State

The core prayer writes are idempotent:

Method	Behavior
`PrayerActions.enable(Prayer)`	Enables one prayer.
`PrayerActions.disable(Prayer)`	Disables one prayer.
`PrayerActions.set(Prayer, boolean)`	Converges one prayer to the requested state.
`PrayerActions.setOnly(Prayer...)`	Converges toward exactly the requested active set.
`PrayerActions.disableAll()`	Converges toward no active prayers.

InteractionResult result = PrayerActions.setOnly(
    Prayer.PROTECT_FROM_MELEE,
    Prayer.PIETY
);
if (result.getStatus() == InteractionStatus.PACED) {
    return; // retry from the next tick
}

setOnly(...) and disableAll() may need multiple ticks because each call queues at most the next required toggle. Re-evaluate and call again until the result succeeds with the requested state already established.

A null prayer returns TARGET_NULL. An unmapped, missing, or hidden prayer component returns PRAYER_WIDGET_NOT_FOUND.

Quick Prayers

For the grouped facade, use PrayerActions (available as PrayerActions):

Method	Behavior
`openQuickPrayers()`	Opens the quick-prayer setup interface.
`selectQuickPrayer(Prayer, boolean)`	Selects or clears one prayer while setup is open.
`setQuickPrayers(Prayer...)`	Converges the configured quick-prayer selection.
`toggleQuickPrayers()`	Toggles the quick-prayer orb.

InteractionResult setup = PrayerActions.setQuickPrayers(
    Prayer.PROTECT_FROM_MAGIC,
    Prayer.MYSTIC_MIGHT
);
if (setup.succeeded() && !PrayerActions.isQuickPrayerEnabled()) {
    InteractionResult toggle = PrayerActions.toggleQuickPrayer(true);
}

Open the setup before calling setQuickPrayers(...). That method compares the selection mask and queues each changed setup child directly in one call; it skips ActionPacer. Toggle the orb only after observing the configured set.

Dwarf Multicannon (`CannonActions`)

CannonActions covers the Dwarf multicannon lifecycle. State reads use rev240 object-ID evidence (DWARF_MULTICANNON1 for a placed cannon, BROKEN_MULTICANNON, and the three build-stage objects); writes are paced and return InteractionResult.

Method	Behavior
`isPlaced()`	A fully built cannon object is present in the scene.
`isBroken()`	A broken cannon object is present.
`isPartiallyBuilt()`	One of the three build-stage objects is present.
`hasSetupKit()`	All four kit parts (base, stand, barrels, furnace) are in the inventory.
`place()`	Uses the cannon base from the inventory; fails closed when a cannon is already placed or partially built, or when the kit is missing.
`load()`	Interacts with the placed cannon (Fire/Load menu actions).
`pickUp()`	Fires the Pick-up action on the placed cannon.
`repair()`	Fires the Repair action on a broken cannon.

Cannonball ammunition state is deliberately unmodeled: rev240 evidence exposes no ammunition varbit, and IDs are never invented. Re-observe isPlaced()/isBroken() after each interaction instead. Live-client verification is pending for the placement, load, pick-up, and repair dispatch.

Workflow Ownership

Combat policy such as food thresholds, target selection, potion use, retries, and death/loot transitions belongs in CombatWorkflowBuilder or the caller's state machine, not in these action methods. See Automation API for that orchestration layer.

For paced tests, call ActionPacer.reset() in @Before. Source and unit test behavior still requires an observed client run.

Combat Settings​

Prayer State​

Quick Prayers​

Dwarf Multicannon (CannonActions)​

Workflow Ownership​

Combat Settings

Prayer State

Quick Prayers

Dwarf Multicannon (`CannonActions`)

Workflow Ownership