Action Execution Order

SSS sorts action fields by this fixed priority, independent of YAML mapping order:

Action-block chance

Shape: chance: number alongside one or more action fields.

The block chance is rolled separately for each action table as SSS processes the rule. A failed roll skips every action field in that block. Omitted chance always permits the block; 0 never does and 1 always does.

instances:
  - actions:
      - chance: 0.5
        add:
          gold_001: 10
        playsound: item_gold

Combining actions

The following example first replaces the target, then transforms the current action target, and finally schedules disable/delete according to their documented target rules.

instances:
  - conditions:
      - record_id: old_creature
    actions:
      - replace:
          new_creature: 1.0
        transform:
          scale: 1.25
        disable: true
        delete: true

replace changes the current action target to a newly created object only when a replacement roll succeeds. With replace: self, that object is created from the original object's record ID. Later transform, teleport, object-property, inventory, script, tag, sound, and disable operations use that replacement target. delete always refers to the original matched source; when it shares an action table with replace, it queues deletion only after a successful replacement. Use a separate delete action table when source deletion must be unconditional.

SSS accumulates transform and teleport placement changes, then performs one engine placement operation after the action list finishes. A teleport starts from the current accumulated cell, position, and rotation, so transforms and teleports compose without depending on the engine applying GameObject:teleport() immediately. A later transform continues from the intended teleported placement and clears an earlier teleport's onGround request. create receives that same accumulated cell, position, rotation, and scale, so pools are based on the pending placement rather than the target's still-committed engine state. A pending onGround: true teleport still contributes its requested, unsnapped position; create cannot observe the later ground-snapped result. playsound remains attached to the target's currently committed engine position. Deletes are queued and processed asynchronously, not necessarily during the handler call. A failed or unsupported action generally no-ops; invalid types, missing required random upper bounds, invalid records, and invalid cells can raise or log according to the action.

See random action ranges for sampled values and the relevant grouped pages for target restrictions and no-op behavior.