Event Manager

Note

You normally never interact with the manager directly. The custom AES Blueprint nodes & static helper functions wrap it for you. This page is reference / internals only.

At a Glance

AES Manager (aka Event Manager) is a World Subsystem, so there is one instance per world context: one on the server and one per connected client. It centralizes event creation, listener registration, and dispatch.

Startup sequence:

1. Asset Manager finishes its initial scan.
2. AES Manager gathers all AES Event classes (Blueprint + C++).
3. Preallocates internal arrays used to hold delegate bindings for each event flavor (Broadcast / Type / Focus / Whisper).

Core Responsibilities

• Initialize & cache event class metadata.
• Maintain the live registry of active Identities.
• Track listeners per event flavor & fast‑dispatch matching delegates.
• Provide internal helpers to generate & enqueue events created via nodes or C++ calls.
• Clean up registrations automatically when an Identity is destroyed.

How Dispatch Works (Simplified)

When an event is generated:

1. The event instance + payload (if any) are created.
2. Manager resolves which registration lists to scan (depends on flavor).
3. Matching delegates are invoked (order is deterministic within each list based on insertion sequence).
4. Temporary payload lifetime ends after dispatch finishes.

Matching Lists

• Broadcast: All Broadcast listeners + any Type or Focus listeners whose filter matches the broadcaster.
• Focus: Only listeners targeting the broadcaster’s Identity ID.
• Type: Only listeners whose Type tag matches the broadcaster’s Type tag.
• Whisper: Only the listener bound to the explicit target Identity (no Broadcast/Type/Focal fan‑out).

Caution

Registering for the same event via Broadcast + Type + Focus can cause multiple delegate executions for one generation if all filters match. Keep registration intent narrow to avoid duplicate handling unless you explicitly need layered behavior.

API Surface & Helpers

Public Blueprint exposure is provided through generated nodes (Register / Unregister / Generate). Under the hood those call into lightweight static / instance methods on the manager.

Internal helper names you may see in C++:

• CreateEventInternal
• GenerateEventInternal
• CreateAndGenerateEvent

These consolidate creation + dispatch steps. Calling a Blueprint‑exposed UFUNCTION directly from C++ is fine; the UFUNCTION spec itself does not add measurable overhead on a native call path—reflection cost only applies when invoked via Blueprint VM or dynamic lookup. The internal versions just keep Blueprint wrappers clean and reduce parameter marshaling duplication.

Tip

If you’re writing C++, prefer a single helper that both creates and generates when you don’t need to mutate the payload between those steps.

Identity & Cleanup

When an Identity is destroyed, the manager automatically removes all of its registrations—manual mass unregister calls are only needed for mid‑lifecycle opt‑out.

When to Think About the Manager

You generally only care if:

• Debugging why a listener didn’t fire (confirm registration exists & filters match).
• Profiling dispatch cost (inspect counts per flavor).
• Extending AES with a custom event flavor or analytics hook.

Otherwise: treat it as infrastructure and use the higher‑level nodes.