Trigger Permissions, Targeting, And Action Pipelines

What This System Is

Trigger permissions, targeting, and action pipelines decide who may activate a scene trigger, which actors it affects, and how immediate or delayed actions execute safely.

How Authors Use It

Authors choose permission policies for player, NPC, combatant, party, admin, local, or remote activation. They choose action targets such as activator, trigger self, party, nearest actor, or named actor group. Delayed actions should include clear cancellation and audit intent.

Rules And Invariants

Authority-sensitive trigger actions must not rely on local prediction alone. Mutation ids and audit labels should remain stable through refactors. Delayed actions need a cancellation path when the activator leaves, dies, or changes authority context.

Validation And Debugging

If a trigger works locally but not online, inspect permission policy and authority route. If the wrong actor receives an action, inspect actor matching and target descriptor. If delayed actions fire twice, inspect pipeline scheduling and mutation ids.

Examples

A party heal trigger can target the activator's party and require player activation. A remote admin trigger should require admin permission and record a stable audit label before mutating scene state.

Related Systems

• Scene Triggers
• Scene Trigger Authority And Reconciliation
• Runtime Actor Identity And Authority Contract