> TagEventBus _

An Event Dispatcher ties a receiver to one specific object. Before a widget can bind to a hit event, it first has to resolve the sender: get it from a manager, find it by class, cast to it in BeginPlay, or hold a reference assigned in the level. Every one of those routes adds the same three things to the receiver — a reference field, a null check, and an implicit assumption about the order in which objects are created.

The number of bindings grows with the number of sender–receiver pairs, not with the number of systems. The problem is the reference graph you have to maintain to connect senders and receivers.

TagEventBus replaces the reference with an address, and that address is an FGameplayTag. The sender announces an event at an address and does not know who is listening; the receiver subscribes to an address and does not know who is broadcasting. The two sides do not have to exist at the same moment. Sticky events let receivers retrieve previously broadcast payloads, so a UI panel opened a second after the round starts can still retrieve the latest stored round state.

But broadcasting on a tag is only the beginning. Then the questions arise: who is actually listening on a given tag, why one particular listener is silent, whether somebody is broadcasting into the void, and whether the payload matches the type the receiver expects. The answers come from an in-editor debugger with a live event stream, tag → struct contracts validated on the sender’s side, priorities with event consumption, and a documented cost for every operation.

What the plugin does not do

These four things are listed here rather than at the end of the documentation, because they determine whether the bus fits your project at all:

• It does not replicate. The bus is local to the game instance; events do not travel over the network. You handle the network boundary with an ordinary RPC, and make a local broadcast on the other side.
• It is not thread-safe. All bus operations run on the game thread. Use the engine’s standard mechanisms to marshal worker-thread results back to it.
• It does not serialize subscriptions. Only sticky payloads persist, and only when you explicitly ask them to.
• It does not aggregate events automatically — beyond the explicit coalescing of deferred broadcasts.

Who it is for

For gameplay programmers working in C++ and in Blueprints. You do not need to write C++: typed structs, sticky payloads, listener groups, and the request layer are all available from Blueprints. Only the payload predicate and the native templated layer — AddListener<T>, the RAII subscriptions, the fluent builder — are C++-only.

From Fab the plugin arrives compiled for your engine version; installed manually from source, it compiles with your project. The entire diagnostic layer is guarded by #if !UE_BUILD_SHIPPING, so it is compiled out of Shipping builds while the production logic remains unchanged.