World Triggers

The World Trigger system pairs a TriggerSensorComponent (condition side) with a WorldTriggerComponent (response side) to create event-driven world state changes. Each component owns an array of polymorphic type objects — sensor types define what conditions to evaluate, trigger types define what happens when the condition passes. Any combination of types can be composed on a single entity without scripting.

For usage guides and setup examples, see The Basics: GS_Interaction.

Contents

• Architecture
• Trigger Sensors
• World Triggers
• Extension Guide
• See Also

Architecture

Breakdown

World Triggers split conditions from responses using a polymorphic type/component pattern. The two container components sit on the entity; logic lives in the type objects they own.

Part	What It Does
TriggerSensorComponent	Owns arrays of TriggerSensorType objects (andConditions, orConditions). Evaluates all conditions and fires WorldTriggerRequestBus::Trigger on success. Automatically activates a PhysicsTriggerComponent if any sensor type requires it.
WorldTriggerComponent	Owns an array of WorldTriggerType objects (triggerTypes). On Trigger(), calls Execute() on every type. On Reset(), calls OnReset(). On Activate(), calls OnComponentActivate() for startup initialization.

No scripting is required for standard patterns. Compose sensor types and trigger types in the editor to cover the majority of interactive world objects.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Trigger Sensors

The sensory side. TriggerSensorComponent holds arrays of TriggerSensorType objects that define evaluation logic — collisions, interactions, record conditions. Supports AND conditions (all must pass) and OR conditions (any must pass).

Trigger Sensors API

World Triggers

The response side. WorldTriggerComponent holds an array of WorldTriggerType objects that execute when triggered — toggling entities, setting records, changing stages, logging messages.

World Triggers API

Extension Guide

Use the ClassWizard templates to generate new sensor and trigger type classes — see GS_Interaction Templates:

• TriggerSensorType — generates a new TriggerSensorType subclass with EvaluateAction(), EvaluateResetAction(), and lifecycle stubs.
• WorldTriggerType — generates a new WorldTriggerType subclass with Execute(), OnReset(), and OnComponentActivate() stubs.

Custom Sensor Types

1. Create a class extending TriggerSensorType.
2. Override EvaluateAction() to define your condition logic.
3. Override EvaluateResetAction() if your type supports reset evaluation.
4. Override Activate(entityId) / Deactivate() for lifecycle setup.
5. If your type needs a physics trigger volume, return true from NeedsPhysicsTrigger().
6. For event-driven types, listen on a bus and call TriggerSensorRequestBus::DoAction() or DoResetAction() when the event fires.
7. Reflect the class manually in GS_InteractionSystemComponent::Reflect().

Custom Trigger Types

1. Create a class extending WorldTriggerType.
2. Override Execute(entityId) — implement the world state change here.
3. Override OnReset(entityId) to reverse or re-arm the effect.
4. Override OnComponentActivate(entityId) for any initial state that must be set at startup.
5. Reflect the class manually in GS_InteractionSystemComponent::Reflect().

See Also

For component references:

• Trigger Sensors
• World Triggers

For related resources:

• Pulsors
• Targeting

Get GS_Interaction

GS_Interaction — Explore this gem on the product page and add it to your project.