GS_Interaction

1 - Pulsors

The Pulsor system is a physics-driven interaction layer. A PulsorComponent emits typed pulses when its physics trigger fires. PulseReactorComponents on other entities receive and process those pulses based on their type. The system is fully extensible — new pulse and reactor types are discovered automatically through O3DE serialization, so new interaction types can be added from any gem without modifying GS_Interaction.

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

Contents

• Architecture
• Components
• Pulse Types
• Reactor Types
• Extension Guide
• See Also

Architecture

Breakdown

When an entity enters a Pulsor’s trigger volume, the Pulsor emits its configured pulse type to all Reactors on the entering entity:

Step	What It Means
1 — Collider overlap	Physics detects an entity entering the Pulsor’s trigger volume.
2 — Pulse emit	PulsorComponent reads its configured PulseType and prepares the event.
3 — Reactor query	Each PulseReactorComponent on the entering entity is checked with IsReactor().
4 — Reaction	Reactors returning true have ReceivePulses() called and execute their response.

Pulse types are polymorphic — new types are discovered automatically at startup via EnumerateDerived. Any gem can define custom interaction semantics without modifying GS_Interaction.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Components

PulsorComponent

Emits typed pulses when its physics trigger fires. Extends AZ::Component and PhysicsTriggeringVolume.

The pulsor fires all configured pulse types simultaneously when an entity enters its trigger volume.

PulseReactorComponent

Receives and processes typed pulses from pulsors.

Bus: PulseReactorRequestBus (ById, Multiple)

Pulse Types

Pulse types define what kind of interaction a pulsor emits. All types extend the abstract PulseType base class.

Pulse Types API

Reactor Types

Reactor types define how an entity responds to incoming pulses. All types extend the abstract ReactorType base class.

Reactor Types API

Extension Guide

Use the ClassWizard templates to generate new pulse and reactor classes with boilerplate already in place — see GS_Interaction Templates:

• PulsorPulse — generates a new PulseType subclass with a named channel and payload stub. Supply type_display_name and type_category input vars to control how it appears in the editor dropdown.
• PulsorReactor — generates a new ReactorType subclass. Supply the required pulse_channel var — the channel string is baked into the header at generation time.

To create a custom pulse or reactor type manually:

1. Create a class extending PulseType (or ReactorType) with a unique RTTI TypeId.
2. Reflect the class using O3DE’s SerializeContext and EditContext. The system discovers the new type automatically.

Channels are string-matched at runtime — keep the channel string consistent between the Pulse and the Reactor that receives it.

See Also

For related resources:

• Targeting
• World Triggers
• Framework API: GS_Interaction

Get GS_Interaction

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

1.1 - Pulse Types

Pulse types define what kind of interaction a PulsorComponent emits. Each pulse type is a data class extending the abstract PulseType base. The PulsorComponent holds an array of pulse types and emits all of them simultaneously when its physics trigger fires.

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

Component

PulsorComponent

Emits configured pulse types when its physics trigger fires. Extends AZ::Component and PhysicsTriggeringVolume.

All pulse types in the array fire simultaneously on a single trigger event. Configure multiple pulse types to target reactors on different channels in one emission.

Base Class

PulseType

Abstract base class for all pulse types. Not a component — discovered automatically at startup via EnumerateDerived and reflected into the editor dropdown.

Subclass PulseType to define custom pulse data (damage values, force vectors, status effect references) and a unique channel name.

Built-in Types

Debug_Pulse

Test and debug pulse for verifying pulsor setups during development.

Use Debug_Reactor on the receiving entity to verify the pulse is arriving correctly.

Destruct_Pulse

Destruction pulse — triggers destructible reactions on receiving entities.

Pair with Destructable_Reactor on entities that should respond to destruction events.

Creating Custom Pulse Types

Use the ClassWizard PulsorPulse template to scaffold a new PulseType subclass with boilerplate already in place — see GS_Interaction Templates. Supply type_display_name and type_category input vars to control how the type appears in the editor dropdown.

To create a custom pulse type manually:

1. Create a class extending PulseType with a unique RTTI TypeId.
2. Override GetChannel() to return a unique channel name string.
3. Add any data fields your pulse carries (damage values, force vectors, status effect references).
4. Reflect the class using O3DE’s SerializeContext and EditContext. The system discovers the type automatically via EnumerateDerived — no registration step required.
5. Configure PulsorComponent instances to emit your custom pulse type.

Keep the channel string consistent between your pulse type and the reactor types that should receive it.

See Also

• Reactors
• Pulsors Overview

Get GS_Interaction

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

1.2 - Reactor Types

Reactor types define how a PulseReactorComponent responds to incoming pulses. Each reactor type is a data class extending the abstract ReactorType base. The PulseReactorComponent holds an array of reactor types and processes all of them when a matching pulse arrives.

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

Component

PulseReactorComponent

Owns and processes reactor types when pulses arrive from PulsorComponent instances. Extends AZ::Component.

Bus: PulseReactorRequestBus (ById, Multiple)

The PulsorComponent queries IsReactor() first — only components that return true have ReceivePulses() called. This allows entities with no reactor types to be skipped without iterating all types.

Base Class

ReactorType

Abstract base class for all reactor types. Not a component — discovered automatically at startup via EnumerateDerived and reflected into the editor dropdown.

Subclass ReactorType to define custom reaction behavior for a specific channel. The channel string must match the emitting PulseType’s channel exactly.

Built-in Types

Debug_Reactor

Test and debug reactor for verifying reactor setups during development. Logs a message when it receives a Debug_Pulse.

Destructable_Reactor

Handles destruction responses — processes Destruct_Pulse events on the receiving entity.

Add this to any entity that should respond to destruction pulses — props, breakables, or enemy characters.

Creating Custom Reactor Types

Use the ClassWizard PulsorReactor template to scaffold a new ReactorType subclass with boilerplate already in place — see GS_Interaction Templates. Supply the pulse_channel input var — the channel string is baked into the generated header at generation time.

To create a custom reactor type manually:

1. Create a class extending ReactorType with a unique RTTI TypeId.
2. Override GetChannel() to return the channel name this reactor listens on.
3. Override React(pulse, sourceEntity) to implement the reaction logic.
4. Reflect the class using O3DE’s SerializeContext and EditContext. The system discovers the type automatically via EnumerateDerived — no registration step required.
5. Add the custom reactor type to PulseReactorComponent instances on entities that should respond.

The channel string in GetChannel() must exactly match the GetChannel() return value of the PulseType you want to receive.

See Also

• Pulses
• Pulsors Overview

Get GS_Interaction

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

2 - Targeting

The targeting system provides spatial awareness and entity selection for units and other entities. A TargetingHandler component serves as the central processor — it receives target registrations from sensory fields, maintains categorized target lists, and selects the best interact target based on proximity and type filtering. The system supports a cursor overlay for visual feedback and an input reader for triggering interactions.

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

Contents

• Components
• EBus Summary
• See Also

Components

EBus Summary

Request Buses

Notification Buses

See Also

For component references:

• Targeting Handler
• Senses & Targeting Fields
• Targets
• Interact Input

For related resources:

• Pulsors
• World Triggers

Get GS_Interaction

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

2.1 - Targeting Handler

The GS_TargetingHandlerComponent is the central processor for the targeting system. It receives target registrations from sensory fields, maintains categorized lists of detected targets, and selects the best interact target based on proximity and type. It also manages cursor feedback and interaction range tracking.

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

The Targeting Handler sits on the same entity as the unit it serves (typically the player or an AI character). Sensory fields register and unregister targets as they enter and exit detection volumes. The handler evaluates all registered targets each tick to determine the closest interactable, which becomes the active interact target.

Contents

• How It Works
• API Reference
• GS_CursorComponent
• GS_CursorCanvasComponent
• Extension Guide
• See Also

How It Works

Target Selection

Each tick, the handler runs ProcessClosestInteractable to evaluate all registered targets. It filters by type, checks interaction range, and selects the closest valid target. The result is broadcast via OnUpdateInteractTarget.

Interaction Range

A separate interaction range field provides a close-proximity subset of targets. Targets within this range are prioritized for interact selection. The range is driven by a dedicated GS_TargetingInteractionFieldComponent trigger volume.

Cursor Tracking

The handler updates the cursor position to follow the active interact target. Cursor visuals change based on target type (interact, item, unit, etc.).

API Reference

GS_TargetingHandlerRequestBus

Bus policy: ById, Multiple

GS_TargetingHandlerNotificationBus

Bus policy: ById, Multiple

Virtual Methods

GS_CursorComponent

Manages cursor display and positioning for targeting feedback.

GS_CursorRequestBus

Bus policy: Single, Multiple

GS_CursorCanvasComponent

UI canvas layer that renders the cursor sprite.

GS_CursorCanvasRequestBus

Bus policy: ById, Multiple

Extension Guide

The Targeting Handler is designed for extension via companion components. Add custom targeting logic by creating components that listen to GS_TargetingHandlerNotificationBus on the same entity. Override ProcessClosestInteractable for custom target selection algorithms.

Script Canvas Examples

Getting the current interact target:

Reacting to interact target changes:

See Also

For conceptual overviews and usage guides:

• Targeting Overview

For component references:

• Targets
• Senses & Targeting Fields
• Interact Input

Get GS_Interaction

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

2.2 - Senses & Targeting Fields

Targeting fields are physics-based detection volumes that feed target registrations into the Targeting Handler. The GS_TargetingInteractionFieldComponent provides proximity detection for interact-range targets. Fields use their own collision layers and should be placed on child entities rather than the main unit capsule.

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

GS_TargetingInteractionFieldComponent

A physics trigger volume that detects targets entering and exiting the interaction range. Extends AZ::Component and PhysicsTriggeringVolume. Registers detected entities with the parent Targeting Handler.

API

Setup

1. Create a child entity under the unit entity that owns the Targeting Handler.
2. Add a PhysX collider configured as a trigger shape.
3. Add the GS_TargetingInteractionFieldComponent.
4. Set the collider to use a dedicated interaction collision layer — do not share the unit’s physics layer.
5. Point the field to the parent Targeting Handler entity.

Extension Guide

Custom sensory fields can be created by extending the base field pattern:

1. Create a component that extends AZ::Component and PhysicsTriggeringVolume.
2. On trigger enter/exit, call RegisterTarget / UnregisterTarget on the Targeting Handler via GS_TargetingHandlerRequestBus.
3. Add custom filtering logic (line of sight, tag filtering, team affiliation) in your trigger callbacks.

See Also

• Targeting Handler
• Targets
• Targeting Overview

Get GS_Interaction

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

2.3 - Targets

Target components mark entities as detectable by the targeting system. The base GS_TargetComponent provides core target data (size, offset, visual properties). Specialized variants like GS_InteractTargetComponent add interaction-specific behavior.

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

GS_TargetComponent

Base target component. Makes an entity visible to the targeting system with configurable visual properties for cursor feedback.

GS_TargetRequestBus

Bus policy: ById, Multiple

GS_InteractTargetComponent

Extends GS_TargetComponent with interact-specific properties. Entities with this component can be selected as interact targets by the Targeting Handler and triggered via the Interact Input system.

Cross-Gem Target Types

Additional target types are conditionally compiled when GS_Interaction is available alongside other gems:

Extension Guide

Create custom target types by extending GS_TargetComponent:

1. Create a new component class extending GS_TargetComponent.
2. Override the target data methods (GetTargetSize, GetTargetOffset, etc.) to return your custom values.
3. Add any additional data fields specific to your target type.
4. The targeting system will automatically detect and categorize your custom targets when they enter sensory fields.

See Also

• Targeting Handler
• Senses & Targeting Fields
• Targeting Overview

Get GS_Interaction

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

2.4 - Interact Input Reader

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

Image showing the InteractInputReader component, as seen in the Entity Inspector.

Interact Input Reader Overview

Extends Input Reader.

This component is a standalone input detector utility to enable Interact Input firing outside of the GS_Unit Gem.

It intakes the Event Name for your chosen interaction input, as defined in your Input Profile and ignores all other input.

Functionality

Interact Input Reader needs to be put in the same entity as the Targeting Handler.

After firing the correct Input Event, the Interact Input Reader requests the current InteractTarget from the Targeting Handler. It then sends a DoInteractAction event, with a reference to its EntityId as caller, to the InteractTriggerSensor component that should be present on the Interact Target.

The World Trigger and Trigger Sensor system takes care of the rest.

Setting Up Your Interact Input Reader

Assure that the component is placed on the same Entity as the Targeting Handler.

Image showing the Interact Input Reader Component alongside the Targeting Handler Component.

Fill the Interact Event Name with the Event Name for your chosen interaction input, as defined in your Input Profile.

So long as the Input Profile that’s set in your GS_OptionsManager has that event set. The rest should work as is.

API

// OptionsManagerNotificationBus
void HandleStartup() override;

// Local Methods (Parent Input Reader Component Class)
void HandleFireInput(AZStd::string eventName, float value) override;

Extending Interact Input Reader

Get GS_Interaction

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

3 - 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.

3.1 - Trigger Sensors

TriggerSensorComponent is the condition container of the World Trigger system. It owns arrays of TriggerSensorType objects that define evaluation logic — collisions, interactions, record checks. When conditions pass, it fires WorldTriggerRequestBus::Trigger on the same entity.

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

Container Component

TriggerSensorComponent

Owns and evaluates all sensor type objects. Not subclassed — extended by adding TriggerSensorType objects to its arrays.

Bus: TriggerSensorRequestBus (ById, Single)

On Activate, automatically activates a PhysicsTriggerComponent on the entity if any sensor type returns true from NeedsPhysicsTrigger().

Base Type Class

TriggerSensorType

Abstract base for all sensor evaluation logic. Not a component — reflected manually in GS_InteractionSystemComponent::Reflect(). Subclass this to add new condition types.

Stores m_ownerEntityId for calling back to TriggerSensorRequestBus::DoAction() or DoResetAction() from event-driven types.

Built-in Sensor Types

SensorType_Collider

Physics overlap sensor. Returns NeedsPhysicsTrigger() = true, causing the owning component to activate a PhysicsTriggerComponent.

• OnTriggerEnter stores the entering entity.
• OnTriggerExit clears the stored entity.
• EvaluateAction() returns true while a valid entity is present.
• EvaluateResetAction() returns true when no entity is present.

SensorType_Record

Fires when a named save record changes to a configured value. Extends RecordKeeperNotificationBus — connects on Activate and fires DoAction automatically when the matching record changes.

• EvaluateAction() calls GetRecord and compares against recordValue.

→ Record Sensor Type Reference

SensorType_Interact

Fires when any unit interacts with this entity via the targeting system. Extends InteractTriggerSensorRequestBus.

• On interact: stores lastCaller and calls DoAction.
• EvaluateAction() returns true while lastCaller is a valid entity.

SensorType_PlayerInteract

Player-only variant of SensorType_Interact. Extends SensorType_Interact and adds a tag check — lastCaller must have the "Player" tag for the condition to pass.

Extension Guide

To create a custom sensor type:

1. Create a class extending TriggerSensorType.
2. Override EvaluateAction() to define when your condition is satisfied.
3. Override Activate(entityId) / Deactivate() to connect and disconnect from any buses.
4. For event-driven evaluation, listen on a bus and call TriggerSensorRequestBus::DoAction(m_ownerEntityId) when the event fires — the component will run the full evaluation pipeline.
5. Return true from NeedsPhysicsTrigger() if your type needs a physics volume.
6. Reflect the class in GS_InteractionSystemComponent::Reflect() — types are not components and are not registered via CreateDescriptor().

See Also

• World Triggers
• World Trigger System

Get GS_Interaction

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

3.1.1 - SensorType_Record

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

Overview

SensorType_Record is a TriggerSensorType that fires when a named save record is changed to a configured value. Add it to the andConditions or orConditions array on a TriggerSensorComponent.

Inherits from RecordKeeperNotificationBus — connects automatically on Activate and listens for record changes without polling. When a matching record change arrives, it calls TriggerSensorRequestBus::DoAction on the owning component, which runs the full condition evaluation pipeline.

Fields

Evaluation

EvaluateAction() calls RecordKeeperRequestBus::GetRecord(recordName) and compares the result to recordValue. Returns true if they match.

The type self-triggers on record change events — you do not need to poll or script a check manually.

Setup

1. Add a TriggerSensorComponent to your entity.
2. Add a SensorType_Record entry to the andConditions or orConditions array.
3. Set recordName to the record you want to watch.
4. Set recordValue to the value that should fire the trigger.
5. Add a WorldTriggerComponent with the desired WorldTriggerType objects to the same entity.

API

From TriggerSensorType:

//! Returns true if the watched record currently matches recordValue.
virtual bool EvaluateAction();

//! Connects to RecordKeeperNotificationBus on component activate.
virtual void Activate(AZ::EntityId entityId);

//! Disconnects from RecordKeeperNotificationBus on component deactivate.
virtual void Deactivate();

From RecordKeeperNotificationBus:

//! Called when any record changes. Fires DoAction if recordName and recordValue match.
virtual void RecordChanged(const AZStd::string& name, int value);

Get GS_Interaction

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

3.2 - World Triggers

WorldTriggerComponent is the response container of the World Trigger system. It owns an array of WorldTriggerType objects that execute when triggered — toggling entities, setting records, changing stages, logging messages.

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

Container Component

WorldTriggerComponent

Owns and drives all trigger type objects. Not subclassed — extended by adding WorldTriggerType objects to triggerTypes.

Bus: WorldTriggerRequestBus (ById)

On Activate(), calls OnComponentActivate(entityId) on every type — use this for initial state seeding (e.g. entity visibility setup before any trigger fires).

Base Type Class

WorldTriggerType

Abstract base for all trigger response logic. Not a component — reflected manually in GS_InteractionSystemComponent::Reflect(). Subclass this to add new response types.

Built-in Trigger Types

Extension Guide

To create a custom trigger type:

1. Create a class extending WorldTriggerType.
2. Override Execute(entityId) — implement your world state change here.
3. Override OnReset(entityId) for reversible or re-armable effects.
4. Override OnComponentActivate(entityId) if your type needs to set up initial state at startup (e.g. TriggerType_ToggleEntities uses this to seed entity visibility).
5. Reflect the class in GS_InteractionSystemComponent::Reflect() — types are not components and are not registered via CreateDescriptor().

See Also

• Trigger Sensors
• World Trigger System

Get GS_Interaction

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

4 - Templates

All GS_Interaction extension types are generated through the ClassWizard CLI. The wizard handles UUID generation, cmake file-list registration, and reflection automatically.

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

python ClassWizard.py \
    --template <TemplateName> \
    --gem <GemPath> \
    --name <SymbolName> \
    [--input-var key=value ...]

Contents

• Pulsor Pulse
• Pulsor Reactor
• World Trigger
• Trigger Sensor

Pulsor Pulse

Template: PulsorPulse

Creates a Pulse — the sender side of the Pulsor system. A Pulse fires on a named channel and carries a typed payload. Any PulsorReactor on the same entity listening to the same channel will receive it.

Generated files:

• Source/${Name}_Pulse.h/.cpp

CLI:

python ClassWizard.py --template PulsorPulse --gem <GemPath> --name <Name> \
    --input-var type_display_name="My Pulse" \
    --input-var type_category="Input"

Input vars:

Post-generation: Implement Fire() with the data payload your channel requires. Match the channel string to the Reactor that will receive it. Each Pulse/Reactor pair is one interaction channel — channels are string-matched.

See also: Pulsors — full pulsor architecture, built-in pulse types, and extension guide.

Pulsor Reactor

Template: PulsorReactor

Creates a Reactor — the receiver side of the Pulsor system. Listens on a specific named channel and executes a response when a matching Pulse fires on the same entity.

Generated files:

• Source/${Name}_Reactor.h/.cpp

CLI:

python ClassWizard.py --template PulsorReactor --gem <GemPath> --name <Name> \
    --input-var pulse_channel=MyChannel \
    --input-var type_display_name="My Reactor" \
    --input-var type_category="Input"

Input vars:

Important: pulse_channel is required. The channel string is baked into the header at generation time. If you need to change it later, edit the m_channel field directly in the generated header.

Post-generation: Implement OnPulse(...) with the response logic. Multiple Reactor instances of different types can coexist on one entity, each listening to a different channel.

See also: Pulsors — full pulsor architecture, built-in reactor types, and extension guide.

World Trigger

Template: WorldTrigger

Creates a WorldTrigger component — a logical trigger in the world that fires a named event when activated. Used to start dialogue sequences, cutscenes, or other scripted events from gameplay code or Script Canvas.

Generated files:

• Source/${Name}_WorldTrigger.h/.cpp

CLI:

python ClassWizard.py --template WorldTrigger --gem <GemPath> --name <Name>

Post-generation: Wire the trigger activation to whatever condition suits the design (physics overlap, input event, distance check, etc.). Override Trigger() — call the parent first to check channels and conditions. Override Reset() for reversible triggers.

See also: World Triggers — full world trigger architecture and extension guide.

Trigger Sensor

Template: TriggerSensor

Creates a TriggerSensor — the listening side of a trigger pair. Registers to receive named trigger events from a WorldTrigger and executes a response action.

Generated files:

• Source/${Name}_TriggerSensor.h/.cpp

CLI:

python ClassWizard.py --template TriggerSensor --gem <GemPath> --name <Name>

Post-generation: Subscribe to the matching trigger event name in Activate(). Override EvaluateAction() to define your trigger condition. Override DoAction() — call the parent first, then add custom behavior if it succeeds. Stack sensors to react to the same trigger in different ways.

See also: Trigger Sensors — full trigger sensor reference.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: GS_Interaction

For all ClassWizard templates across GS_Play gems:

• Templates List

Get GS_Interaction

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

5 - 3rd Party Implementations

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

Get GS_Interaction

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