SignalBus Broadcast Graph

Review draft. This source page has not completed website editorial and release-specific verification.

The Broadcast Graph is a read-only visualization inside the SignalBus Runtime Inspector.

It shows the runtime message topology that SignalBus has observed:

Publisher -> Message -> Subscriber

Use it to answer questions such as:

• Which objects have published a message?
• Which subscribers are currently listening?
• Is the route using World or Game Instance scope?
• Which payload type belongs to the message?
• Is activity occurring in the expected PIE context?
• Are publishers and subscribers connected through the same contract?
• Are warnings associated with the route?

The graph does not control SignalBus. It displays copied runtime snapshots and retained diagnostic information.

---

Core Model

Every route is represented with three node categories:

Publisher node
    -> Message node
        -> Subscriber node

Example:

BP_Door_Entrance
    -> World.DoorOpened
        -> BP_QuestManager
        -> BP_AudioManager
        -> BP_HUDController

This means:

• BP_Door_Entrance was observed publishing the message.
• The message belongs to the selected SignalBus context.
• The listed subscribers currently have matching active subscriptions.

The graph alone does not prove that every subscriber ran during every publish. Use Event History and dispatch details to verify actual callback execution.

---

Opening the Broadcast Graph

1. Open the SignalBus Runtime Inspector.
2. Start PIE or connect to an available runtime context.
3. Select the desired World or Game Instance context.
4. Open the Broadcast Graph view.
5. Trigger the gameplay or Blueprint action you want to inspect.
6. Wait for the Inspector refresh.
7. Pan, zoom, select nodes, and review tooltips or details.

The graph may be empty before PIE starts, before subscriptions are created, or before any publisher activity is observed.

---

Context Selection

Every graph belongs to one selected SignalBus context.

Typical Multi-PIE contexts include:

World - PIE 0
Game Instance - PIE 0
World - PIE 1
Game Instance - PIE 1

The selected context determines which publishers, messages, subscribers, queues, diagnostics, and warnings are displayed.

World and Game Instance data are never merged. Separate PIE instances are never merged.

For example, selecting:

World - PIE 0

will not display routes from:

World - PIE 1
Game Instance - PIE 0

This matches SignalBus runtime isolation.

---

Node Types

Publisher Nodes

Publisher nodes represent objects that SignalBus has observed publishing messages.

Examples:

BP_Door_Entrance
BP_PlayerCharacter
BP_SaveManager
UQuestSubsystem

Publishers are not permanently registered with SignalBus. They are inferred from retained diagnostic history.

A publisher may not appear when:

• It has not published yet.
• Diagnostics were disabled when it published.
• Diagnostic history was cleared.
• Its old event was evicted from bounded history.
• The wrong context is selected.
• PIE restarted and the previous context was destroyed.

A missing publisher node does not automatically mean publishing is broken. It may only mean the graph has no retained evidence of that publisher.

Message Nodes

A message node represents one specific SignalBus contract:

Scope + Context + Message ID + Exact Payload Type

Example:

Scope: World
Message ID: Combat.HealthChanged
Payload Type: ST_HealthChanged

The same Message ID can produce separate message nodes when it is used with different scopes, contexts, or payload types.

Example:

World / Combat.HealthChanged / ST_HealthChanged
Game Instance / Combat.HealthChanged / ST_HealthChanged

These are separate routes.

Another example:

World / Combat.Event / ST_DamageApplied
World / Combat.Event / ST_HealingApplied

These are also separate contracts because SignalBus uses exact reflected payload-type matching.

Recommended convention:

One Message ID
One payload struct
One intended scope

This keeps the graph and diagnostics easier to understand.

Subscriber Nodes

Subscriber nodes come from active subscription snapshots.

Examples:

BP_QuestManager.SignalBusListener
BP_HUDController.SignalBusListener
UAudioReactionComponent

A subscriber may appear before the first publish because its subscription is active runtime state.

A subscriber disappears when:

• It unsubscribes.
• Its lifetime owner is destroyed.
• Its subscription expires and is pruned.
• PIE ends.
• The selected context changes.
• The owning subsystem is destroyed.

If a subscriber is missing, check the Inspector’s Active Subscriptions table first.

---

Edges

Edges connect:

Publisher -> Message
Message -> Subscriber

Publisher-to-Message Edge

This means the publisher was observed publishing that message contract.

It does not mean the publisher is permanently registered or bound to the message.

Message-to-Subscriber Edge

This means the subscriber currently has an active matching subscription.

It does not guarantee that the subscriber ran during every observed publish.

A callback may not have run because:

• The subscriber unsubscribed before delivery.
• Its lifetime owner expired.
• The payload type did not match.
• A queued message has not been processed yet.
• The subscription was created after an immediate publish completed.
• The selected diagnostic event belongs to another context.

Use Event History and dispatch details to confirm actual invocation.

---

Immediate and Queued Activity

The graph represents topology, not execution timing.

Immediate and queued messages may produce the same visual route:

Publisher -> Message -> Subscriber

Use details to inspect:

• Dispatch mode
• Dispatch ID
• Queue ID
• Publish count
• Invocation count
• Queue delay
• Callback duration
• Related warnings

Immediate example

BP_PlayerCharacter
    -> Combat.HealthChanged
        -> BP_HUDController

Expected execution order:

Before Publish
Subscriber Callback
After Publish

Queued example

BP_InventoryManager
    -> Inventory.Refreshed
        -> BP_InventoryWidget

Expected execution order:

Before Queue
After Queue
Subscriber Callback

The graph can look identical in both cases. Check Dispatch Mode, Queue ID, and Event History to distinguish them.

---

Example Scenario 1: Door Event

Runtime setup

Publisher:

BP_Door_Entrance

Message:

World.DoorOpened

Payload:

ST_DoorOpened

Subscribers:

BP_QuestManager
BP_AudioManager
BP_MapMarkerManager

Expected graph

BP_Door_Entrance
    -> World.DoorOpened
        -> BP_QuestManager
        -> BP_AudioManager
        -> BP_MapMarkerManager

What this proves

• The door published the expected message.
• The message belongs to the selected World context.
• Three matching subscriptions are active.
• The payload contract is ST_DoorOpened.

What it does not prove by itself

• That all three callbacks completed.
• Whether delivery was Immediate or Queued.
• Whether one subscriber unsubscribed during dispatch.
• Whether payload values were correct.
• Whether a warning was generated.

Use the Inspector details for those questions.

---

Example Scenario 2: Save Completion

Publisher:

BP_SaveManager

Message:

Save.Completed

Payload:

ST_SaveCompleted

Subscribers:

BP_FrontendController
BP_NotificationManager

Expected context:

Game Instance - PIE 0

Expected graph:

BP_SaveManager
    -> Save.Completed
        -> BP_FrontendController
        -> BP_NotificationManager

If this route appears only in the World graph, the publisher or subscribers may be using the wrong scope.

---

Example Scenario 3: Multiplayer PIE

Two-client PIE may contain separate graphs such as:

World - PIE 0

BP_ServerDamageSystem
    -> Combat.DamageApplied
        -> BP_ServerQuestManager

World - PIE 1

BP_ClientHealthComponent
    -> Combat.HealthChanged
        -> BP_ClientHUD
        -> BP_ClientAudio

SignalBus does not connect these graphs.

Unreal replication or RPCs must move state between server and clients. Each local context may then publish its own SignalBus message.

---

Labels, Tooltips, and Details

Node labels use compact names to keep the graph readable.

Example compact label:

BP_HUDController

The full identity may be much longer:

/Game/Maps/UEDPIE_0_TestMap.TestMap:PersistentLevel.BP_HUDController_C_0.SignalBusListener

Full identities remain available through:

• Tooltips
• Inspector details
• Diagnostic records

Edge labels are hidden by default because large graphs become difficult to read when every edge contains text.

Select a node or edge to inspect information such as:

• Scope
• Context
• Message ID
• Payload type
• Publisher identity
• Subscriber identity
• Subscription handle
• Dispatch count
• Dispatch mode
• Dispatch ID
• Queue ID
• Warning state

---

Navigation

Pan

Drag the graph background to move through the topology.

Zoom

Use the mouse wheel or the graph’s zoom controls.

Fit All

Use Fit All to frame the visible topology.

Fit All uses full node bounds rather than only node centers.

Stable positions

Within one editor session, stable node IDs help preserve node positions across refreshes.

The graph should not automatically fit itself on every refresh. This lets you inspect one area without the viewport constantly moving.

---

Layout Behavior

Broadcast Graph layout is session-only.

Positions are not permanently stored across:

• Editor restarts
• Project reopen
• New PIE sessions where runtime identities change
• Diagnostic-history resets

Manually adjusted positions may be lost when the graph is rebuilt.

Persistent graph layouts are not provided in SignalBus 1.0.0.

---

Graph Limits and Stress Validation

The graph enforces visible node and edge limits to protect editor responsiveness.

The implementation passed synthetic model tests with:

250 nodes
1,000 edges

These tests verified that graph-model construction and the editor view remain functional with substantial topology data.

When visual limits are exceeded, the graph may:

• Omit lower-priority detail.
• Limit displayed nodes.
• Limit displayed edges.
• Enter a large-graph display mode.
• Require stronger filtering.

Runtime SignalBus behavior is not changed. Messages continue routing even when the graph cannot display every route.

---

Performance Guidance

The graph is a debugging tool, not a permanent high-volume gameplay monitor.

For clearer and faster results:

• Select one context.
• Use stable Message IDs.
• Avoid publishing every Tick.
• Clear history before reproducing one issue.
• Disable unrelated test publishers.
• Use one payload type per Message ID.
• Close the Inspector when it is not needed.
• Reduce unrelated diagnostic activity.

The graph refreshes from copied snapshots. It does not retain mutable references to runtime subsystem arrays.

---

Observational-Only Behavior

The Broadcast Graph cannot:

• Publish messages
• Replay messages
• Subscribe listeners
• Unsubscribe listeners
• Cancel queued messages
• Edit payloads
• Change routing
• Change callback order
• Repair warnings
• Replicate messages
• Scan C++ source
• Scan Blueprint source
• Persist node layout

Opening, closing, panning, zooming, or selecting graph elements does not change gameplay behavior.

---

Publisher Discovery Limitation

Publisher nodes depend on retained diagnostics.

This creates a common valid state:

Subscriber exists
Publisher missing

The subscriber is actively registered, but no publisher activity may exist in retained history.

To make the publisher appear:

1. Enable diagnostics for the selected context in SignalBus Runtime Controls.
2. Select the correct context.
3. Trigger the publish.
4. Wait for Inspector refresh.
5. Confirm the publish event appears in Event History.
6. Reopen or refresh the graph if necessary.

Clearing history afterward may remove the publisher again.

---

Troubleshooting

Graph is completely empty

Check:

1. Is PIE running?
2. Is the correct context selected?
3. Are diagnostics enabled?
4. Has any publisher actually published?
5. Has any subscriber registered?
6. Is the Inspector attached to the expected subsystem?
7. Did PIE restart and create new context identities?

An empty graph before runtime activity is normal.

Subscriber is missing

Possible causes:

• The Subscribe node never executed.
• Wrong scope was selected.
• Message ID differs.
• Payload Type Sample differs.
• Listener Component is missing.
• The Actor already ended play.
• Auto-unsubscribe removed the handle.
• Manual unsubscribe already ran.
• Wrong PIE context is selected.

Check Active Subscriptions first. If the subscription is absent there, the graph is correctly omitting it.

Publisher is missing

Possible causes:

• It has not executed.
• Diagnostics were disabled.
• History was cleared.
• History was evicted.
• Wrong context is selected.
• Publish was rejected.
• Publisher identity was unavailable.
• PIE restarted.

Check Event History for the publish. Remember that publishers are observed, not registered.

Message node appears twice

Possible causes:

• The same Message ID uses two payload types.
• The same Message ID is used in World and Game Instance scopes.
• Two PIE contexts are being compared.
• Message naming is inconsistent.

Inspect each node’s:

Scope
Context
Payload Type

The duplicate may represent two valid, separate contracts.

Publisher and subscriber do not connect

Check all three routing keys:

Scope
Message ID
Exact payload type

Example mismatch:

Publisher:
World
Combat.HealthChanged
ST_HealthChanged

Subscriber:
World
Combat.HealthChanged
ST_HealthChangedExtended

These do not connect.

Queued message appears but subscriber does not run

Possible causes:

• The queue has not processed yet.
• Subscriber was removed before delivery.
• Subscriber owner expired.
• Payload type differs.
• Queue belongs to another context.
• Queue processing limits delayed it.
• The message was queued during an active processing pass and waits for the next pass.

Check:

• Pending Queue
• Queue ID
• Dispatch ID
• Event History
• Subscriber invocation records

Graph shows old publisher activity

Publisher nodes may remain while diagnostic history retains old events.

Use Clear History in SignalBus Runtime Controls for the selected context to remove retained publisher evidence.

This does not unsubscribe listeners or change routing.

Graph changes after clearing history

This is expected.

Subscribers may remain because they come from active subscriptions.

Publishers may disappear because they come from retained diagnostic history.

Message nodes that existed only because of publisher history may also disappear.

Wrong server or client data appears

Verify the selected context.

In Multi-PIE, check:

PIE instance
Scope
World identity
Game Instance identity

Most apparent cross-context problems are caused by viewing a different context in the Inspector.

If events truly appear in the wrong context, treat that as a serious subsystem-resolution defect and reproduce it with diagnostics enabled.

Graph is too crowded

Try:

• Select one context.
• Clear retained history in SignalBus Runtime Controls.
• Reproduce only one message flow.
• Filter by Message ID.
• Filter by payload type.
• Disable unrelated systems.
• Use compact Message ID names.
• Avoid reusing one Message ID for multiple payload contracts.
• Keep edge labels hidden.

Nodes overlap or look folded together

Use:

• Fit All
• Manual node movement
• Additional zoom
• Context filtering
• History clearing
• A smaller reproduction scenario

Stable layout reduces unnecessary movement, but large topologies may still need manual organization.

Graph does not update immediately

The Inspector refreshes periodically instead of rebuilding on every event.

Check:

• Auto-refresh is enabled.
• The graph tab remains open.
• PIE is active.
• The selected context still exists.
• Diagnostics are enabled for publisher discovery.

Wait for the next refresh cycle.

---

Recommended Debugging Workflow

Use this workflow when a message is not received:

1. Open the SignalBus Runtime Inspector.
2. Select the expected World or Game Instance context.
3. Open Active Subscriptions.
4. Confirm the subscriber exists.
5. Confirm its Message ID and payload type.
6. Clear diagnostic history.
7. Trigger one publish.
8. Check Event History.
9. Open Broadcast Graph.
10. Confirm the Publisher-to-Message edge.
11. Confirm the Message-to-Subscriber edge.
12. Inspect dispatch details.
13. Check warnings.
14. Verify Immediate versus Queued timing.

This separates topology problems from callback-execution problems.

---

Interpreting Common Graph Shapes

One publisher, many subscribers

Publisher
    -> Message
        -> Subscriber A
        -> Subscriber B
        -> Subscriber C

This is normal fan-out.

Many publishers, one subscriber

Publisher A
Publisher B
Publisher C
    -> Message
        -> Subscriber

Example:

Several doors
    -> World.DoorOpened
        -> Quest Manager

Publisher with no subscriber

Publisher
    -> Message

Possible meanings:

• No active subscription exists.
• Subscriber uses the wrong scope.
• Subscriber expects the wrong payload type.
• Subscriber was destroyed.
• The event is intentionally fire-and-forget.

The warning system may report no-subscriber activity depending on configuration.

Subscriber with no observed publisher

Message
    -> Subscriber

Possible meanings:

• Subscriber is waiting normally.
• No publish has occurred yet.
• Publisher history was cleared.
• Diagnostics were disabled during publishing.
• Publisher activity was evicted.

This is not automatically an error.

Similar message nodes

Combat.HealthChanged / ST_HealthChanged
Combat.HealthChanged / ST_HealthChangedDetailed

This indicates separate exact payload contracts.

Consider using distinct Message IDs to reduce ambiguity.

---

Validation Coverage

The Broadcast Graph implementation passed automated validation covering:

• Editor tab construction
• Graph model construction
• Stable topology modeling
• World and Game Instance separation
• Publisher and subscriber modeling
• Readability corrections
• Large synthetic graph input
• 250-node model input
• 1,000-edge model input
• Runtime/editor module separation
• Inspector regression coverage

These tests verify model correctness and editor stability. They do not turn the graph into a routing authority.

---

Which Inspector View Should You Use?

Use Broadcast Graph for:

• Runtime topology
• System coupling
• Missing subscriptions
• Unexpected publishers
• Scope mistakes
• Payload-contract mistakes
• Fan-out relationships
• Multi-PIE context separation

Use Event History for:

• Exact execution order
• Dispatch results
• Invocation counts
• Queue timing
• Callback timing
• Rejections
• Individual Dispatch IDs

Use Active Subscriptions for:

• Whether a listener is registered
• Subscription Handle
• Scope
• Message ID
• Expected payload type
• Lifetime owner

Use Pending Queue for:

• Deferred delivery
• Queue backlog
• Queue IDs
• FIFO order
• Processing delays

Use Warnings for:

• No-subscriber activity
• Slow subscribers
• Queue backlog
• Repeated or high-rate behavior
• Other configured warning rules

---

Summary

Publisher nodes
    = observed from retained diagnostics

Message nodes
    = Scope + Context + Message ID + Payload Type

Subscriber nodes
    = current active subscriptions

The Broadcast Graph is best understood as:

A live, read-only topology map of observed SignalBus activity

When troubleshooting, verify:

Correct context
Correct scope
Exact Message ID
Exact payload type
Active subscription
Observed publish
Expected dispatch mode