Manual Registration and Global Delegates

• Initialization Order
• Register Effect Definitions
• Route Incoming Requests
• Send Exactly One Response
• Clone Registered Effects
  • Recreate Clones After Reconnection
• Menu and Game-State Updates
• Reconnection

Effect components are recommended for straightforward instant and timed effects. Use the subsystem's setup functions and global delegates when:

• one manager routes many effects,
• you need Blueprint-defined parameter metadata,
• timed effects need custom stacking behavior,
• effects are created from data rather than actor components.

Initialization Order

1. Get UCrowdControlSubsystem.
2. Bind OnConnectionStateChanged, OnSessionReady, and the required trigger delegates.
3. Call Connect.
4. From OnSessionReady, register each effect.

Do not add an arbitrary delay after connection. OnSessionReady is the authoritative signal, and each setup function checks IsInitialized.

Register Effect Definitions

Choose the function that matches the menu definition:

Function	Definition	Trigger
Setup Effect	FCrowdControlEffectInfo	OnEffectTrigger
Setup Timed Effect	FCrowdControlTimedEffectInfo	OnTimedEffectTrigger
Setup Parameter Effect	FCrowdControlParameterEffectInfo	OnParameterEffectTrigger

Effect IDs must be stable, unique, lowercase, and contain no spaces.

Registration populates both the native runtime and the menu manifest used by PrintEffectsToJsonFile.

Route Incoming Requests

Each trigger includes a request ID and the registered EffectID. Branch or map by EffectID, then pass the request to the correct gameplay system.

The delegates also include ViewerName. Timed triggers add Duration; parameter triggers add quantity and a JSON parameter object.

Bind each delegate once per intended handler. Multiple objects may listen, but only one handler should own the response for a given request.

In the example above, the called gameplay function must also send the response using the incoming request ID.

Send Exactly One Response

Every request must eventually receive one response:

Function	Meaning
Effect Success	The gameplay change was applied.
Effect Success With Message	Success plus a viewer-facing message.
Effect Failure / Effect Failure With Message	Temporary failure using the compatibility response functions.
Effect Failure Temporary	The effect cannot run now and may be retried.
Effect Failure Permanent	The request can never run and must not be retried.

Responses may be asynchronous. Preserve the request ID through latent actions, level loads, or other async work.

Clone Registered Effects

Clones let multiple effect IDs reuse one registered implementation. A clone can be created from any Blueprint action at any time after the subsystem is initialized and the source has been registered with Setup Effect, Setup Timed Effect, Setup Parameter Effect, or an effect component. It does not have to be created directly from OnSessionReady.

Node	Use
Clone Effect	Create one alias from Source Effect ID to Destination Effect ID.
Clone Effect to IDs	Create several aliases in one atomic operation.

Use Clone Effect when creating one new ID from a registered source:

Use Clone Effect to IDs with Make Array when creating several IDs from the same source:

In both examples, the incoming execution wire is intentionally shown without an upstream node. It can originate from any action appropriate to the game, provided the subsystem is initialized and heal_player_p1 is already registered. For example, clones may be created during initial session setup, when a level loads, or when gameplay unlocks new effect variants.

The destination ID must be non-empty, unique, and not already registered. For Clone Effect to IDs, every destination must be valid and unique. The operation is atomic: if any destination is rejected, no clones in that call are created.

Each clone copies the source runtime definition and menu metadata. Incoming requests retain the destination EffectID, but effect-component clones route to the source component. Global delegate handlers should branch or map on the received EffectID when aliases require different gameplay values.

The Boolean return value reports whether the clone operation succeeded. Branch on it when the calling Blueprint needs to report or recover from setup failures.

Call PrintEffectsToJsonFile after cloning if the destination IDs should appear in the submitted menu manifest.

Recreate Clones After Reconnection

Runtime registrations are rebuilt when a new session becomes ready. If a clone must always exist, put source registration and its clone calls in the same idempotent routine invoked by OnSessionReady:

1. Register the source effect.
2. Clone it to the required destination IDs.
3. Check the clone node's Boolean return value.
4. Generate the menu JSON only after all registrations and clones are complete.

Do not clone before the source is registered, and do not add arbitrary delays to make registration order work.

Menu and Game-State Updates

Use:

• SetEffectVisibility
• SetEffectAvailability
• ShowEffectsByIDs / HideEffectsByIDs
• EnableEffectsByIDs / DisableEffectsByIDs

to keep the menu aligned with game state.

When the game pack consumes live metadata, see Sending Pack Metadata for the single-value and JSON Blueprint nodes.

Reconnection

OnSessionReady can fire again after a reconnect. Avoid creating duplicate delegate bindings, and ensure your registration routine can safely rebuild the current effect set.

Continue with Starting a Session and Testing Effects.