ApplyStatus

An ApplyStatus action adds a buff or debuff to each resolved target. Add it to a skill's actions array with type: "apply_status".

Configure the status inside status_to_apply. Shared status settings and type-specific settings belong in the same object.

See Status for the supported status families and gameplay concepts.

Resolution order

Cowculator resolves an ApplyStatus action in this order:

1. Resolve the action's targets.
2. Check the action's chance independently for each target.
3. Create a new status instance for each successful target.
4. Compare its name with statuses already on that target.
5. Apply, replace, or reject the status according to its stacking configuration.

A missed target receives no status. With target_type: "all", the status can be applied to one fighter and miss the other.

Reapplication and stacking

Cowculator matches existing statuses by their exact name. When statuses with that name are already active, a new application uses their established stack_policy and max_stacks values, even when its own configuration differs. The values come from the first status applied while that name remains active:

Established values	Reapplication behavior
stack_policy: "replace"	Remove all same-name instances and replace them with the new status
stack_policy: "stack", below max_stacks	Add the new status as an independent stack
stack_policy: "stack", at max_stacks	Reject the new status and leave all existing stacks unchanged

Each accepted stack has its own runtime status ID and remaining duration. A rejected application does not refresh, replace, or otherwise change any existing stack.

Accepted applications inherit those values. They remain unchanged if the oldest same-name stack expires or is removed. Once no same-name status remains active, the next application uses its own configuration.

Existing stacks keep their settings

Poison first arrives with stack_policy: "stack" and max_stacks: 3. While any stack remains, a same-name Poison configured with stack_policy: "replace" is still added as another stack. If three Poison stacks are already active, the new application is rejected. After all Poison stacks disappear, a new replace-policy Poison can use its own configuration.

A replace-policy application produces a replace_status battle event. An application rejected at max_stacks produces apply_status_rejected with the current and maximum stack counts. Use these structured events and runtime status IDs when updating status displays or replaying battle events.

See Shields for how independent shield stacks contribute to the combined shield value.

Apply a stat buff

This action applies a stacking attack buff to its caster:

{
  "type": "apply_status",
  "name": "Apply attack up",
  "chance": 1.0,
  "target_type": "self",
  "status_to_apply": {
    "name": "Attack Up",
    "target_type": "self",
    "status_type": "buff",
    "type": "stats_up",
    "removable": true,
    "duration": 3,
    "stack_policy": "stack",
    "max_stacks": 3,
    "stat_data": [
      { "stat": "attack", "value": 0.5 }
    ]
  }
}

Apply a DOT debuff

This action applies poison to the opposing fighter:

{
  "type": "apply_status",
  "name": "Apply poison",
  "chance": 1.0,
  "target_type": "enemy",
  "status_to_apply": {
    "name": "Poison",
    "target_type": "enemy",
    "status_type": "debuff",
    "type": "dot",
    "removable": true,
    "duration": 2,
    "stack_policy": "replace",
    "damage_type": "current_health_percent",
    "value": 0.1
  }
}

See Damage over time for DOT timing, damage types, reduction, and rounding.

Looking for exact fields?

Use the OpenAPI reference for each concrete status schema and its validation rules.