SignalBus Runtime Inspector

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

The SignalBus Runtime Inspector is an editor-only debugging tool for viewing live SignalBus activity.

Open it from:

Tools → Director Suite → Runtime Inspectors → SignalBus Runtime Inspector

The Inspector displays copied runtime snapshots. It does not hold direct mutable references to live SignalBus storage, so opening or closing it does not change routing.

What It Is For

Use the Inspector to answer questions such as:

• Is my subscriber registered?
• Did a message publish?
• Was it Immediate or Queued?
• Which payload type was used?
• Which World or Game Instance handled it?
• Is a queued message still waiting?
• Did a warning occur?
• Which publishers and subscribers are connected?
• Am I viewing the wrong PIE context?

The Inspector is observational only. It does not publish, replay, edit payloads, subscribe, unsubscribe, clear queues, repair warnings, change callback order, replicate messages, or modify gameplay state.

Opening the Inspector

1. Open Tools → Director Suite → Runtime Inspectors → SignalBus Runtime Inspector.
2. Start PIE.
3. Select the correct SignalBus context.
4. If no new diagnostics appear, use Runtime Controls to enable diagnostics for this context.
5. Trigger the gameplay event.
6. Review subscriptions, queue state, history, warnings, and graph topology.

Before PIE starts, the Inspector may show no runtime contexts.

Contexts

Each SignalBus subsystem appears as a separate context.

Examples:

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

Each context has separate:

• Subscriptions
• Pending queue
• Diagnostic history
• Warnings
• Payload snapshots
• Broadcast Graph state

The Inspector never merges these automatically.

World Context

A World context represents one USignalBusWorldSubsystem.

Use it for map, match, Actor, and gameplay events such as:

Combat.DamageApplied
Enemy.Spawned
Door.Opened
Objective.ProgressChanged
Projectile.Impact

When the World is destroyed, that context disappears.

Game Instance Context

A Game Instance context represents one USignalBusGameInstanceSubsystem.

Use it for local session-level and cross-travel events such as:

Profile.Loaded
Save.Completed
Login.StatusChanged
Travel.Started
Travel.Completed
Matchmaking.SearchStarted

The Game Instance context may remain while one World is destroyed and another is created.

Multi-PIE

In Multi-PIE, server and client Worlds may exist in one editor process. The Inspector lists each separately.

A server World publish should not appear inside a client World context unless the client separately publishes its own local message after replication or an RPC.

Main Panels

The main panels are:

Active Subscriptions
Pending Queue
Event History
Warnings
Broadcast Graph

Each panel shows information only for the selected context.

Active Subscriptions

Shows currently registered subscribers.

Typical fields include:

• Subscription handle
• Message ID
• Payload type
• Subscriber identity
• Lifetime owner
• Insertion order
• Scope
• Context

Use this panel first when a listener does not receive a message.

Example:

Message ID: Combat.HealthChanged
Payload Type: ST_HealthChanged
Subscriber: BP_HUDController.SignalBusListener
Scope: World

If the subscription is missing, likely causes include:

• Subscribe node never executed
• Wrong scope
• Wrong payload type sample
• Missing Listener Component
• Actor already ended play
• Manual unsubscribe ran
• Auto-unsubscribe removed the handle
• Wrong PIE context is selected

Subscribers are explicitly registered, so they may appear before any publisher has sent a message.

Pending Queue

Shows queued messages that were accepted but have not yet been delivered.

Typical fields include:

• Queue ID
• Message ID
• Payload type
• Publisher identity
• Enqueue order
• Pending count
• Scope
• Context

Example:

Queue ID: 42
Message ID: Inventory.Refreshed
Payload Type: ST_InventoryRefreshed
Status: Pending

A queued message may remain pending because:

• The next queue-processing pass has not occurred
• It was queued during an active processing pass
• A large backlog exists
• The context is paused or not ticking
• The message belongs to another context

Queued means deferred, not timed. The Inspector cannot cancel or reorder queued messages.

Event History

Event History shows retained diagnostic events for the selected context.

Possible events include:

• Subscription added
• Subscription removed
• Immediate publish started
• Publish rejected
• Message queued
• Queue rejected
• Dispatch started
• Subscriber invoked
• Subscriber completed
• Dispatch completed
• Warning state changes
• Context lifecycle events

Details may include:

• Message ID
• Payload type
• Publisher
• Subscriber
• Dispatch mode
• Dispatch ID
• Queue ID
• Callback duration
• Dispatch duration
• Queue delay
• Result counts
• Failure reason

Immediate Example

Expected event sequence:

ImmediatePublishStarted
DispatchStarted
SubscriberInvoked
SubscriberCompleted
DispatchCompleted

Blueprint execution order:

Before Publish
Receive Callback
After Publish

Queued Example

Expected event sequence:

MessageQueued
QueuedDispatchStarted
SubscriberInvoked
SubscriberCompleted
QueuedDispatchCompleted

Blueprint execution order:

Before Queue
After Queue
Receive Callback

Use Queue ID and Dispatch ID to correlate enqueue and later delivery.

Warnings

Warnings show runtime diagnostic conditions for the selected context.

Examples may include:

• No subscribers
• Slow subscriber callback
• Queue backlog
• Repeated high-rate publishing
• Payload inspection issues
• Expired subscription cleanup

Typical fields include:

• Warning type
• Severity
• Message ID
• Subscription handle
• Queue ID
• Dispatch ID
• Occurrence count
• First occurrence
• Last occurrence
• Resolved state
• Summary

Warnings do not change routing.

For example:

No Subscriber warning

does not create a subscriber.

Slow Subscriber warning

does not cancel the callback.

Queue Backlog warning

does not clear the queue.

Broadcast Graph

The Broadcast Graph shows:

Publisher -> Message -> Subscriber

Publisher nodes come from retained diagnostic history.

Subscriber nodes come from active subscriptions.

Message nodes represent:

Scope
Context
Message ID
Payload type

Use it to find:

• Missing subscribers
• Unexpected publishers
• Scope mismatches
• Payload contract mismatches
• Large fan-out routes
• Multi-PIE isolation issues

The graph does not prove every subscriber ran during every publish. Use Event History for exact dispatch behavior.

Runtime Settings

Runtime settings are intentionally managed in SignalBus Runtime Controls. The Inspector displays the selected context’s current diagnostic snapshots and payload policy but cannot change diagnostic capture, warning analysis, payload capture policy, retained event history, or retained warnings.

Open Tools → Director Suite → Runtime Controls → SignalBus Runtime Controls to make those changes. Clearing retained history or warnings does not alter message delivery.

Payload Viewer

Payload snapshots are read-only diagnostic representations captured during publish or enqueue.

They may show:

• Payload type
• Struct size
• Property names
• Supported values
• Container summaries
• Truncation state
• Inspection policy
• Hidden-property markers

Snapshots do not contain live editable references to the original runtime payload.

Hidden Properties

Properties marked with SignalBusHidden are not shown by value and are not searchable by that hidden value.

Example:

UPROPERTY(meta = (SignalBusHidden))
FString AuthenticationToken;

The Inspector may show that the property exists, but not its contents.

Snapshot Limits

Typical limits include:

Payload snapshot budget: 64 KiB
Container inspection limit: 64 elements
Nested depth limit: 8
Scalar text limit: 1,024 characters

Large payloads may be marked Truncated. This affects only diagnostic capture, not delivery.

Common Workflows

Subscriber Does Not Receive a Message

1. Select the expected context.
2. Open Active Subscriptions.
3. Confirm the subscriber exists.
4. Confirm the Message ID.
5. Confirm the exact payload type.
6. Open Event History.
7. Trigger one publish.
8. Confirm the publish was accepted.
9. Check whether dispatch occurred.
10. Check subscriber invocation records.
11. Review Warnings.

Common causes are wrong scope, Message ID typo, payload mismatch, missing subscription, wrong PIE context, or queued delivery not yet processed.

Queued Message Did Not Deliver

1. Open Pending Queue.
2. Find the Queue ID.
3. Wait for the next processing pass.
4. Check Event History for queued dispatch start.
5. Confirm the subscriber was still active at delivery.
6. Check queue backlog warnings.
7. Verify the context is ticking.

Queued payloads are copied at enqueue. Subscribers are matched at delivery.

Wrong Server or Client Behavior

1. Confirm whether the selected context is server or client.
2. Confirm World versus Game Instance.
3. Check the PIE instance.
4. Inspect publisher identity.
5. Confirm replication or RPC arrived first.
6. Confirm the local SignalBus publish occurred in the intended context.

SignalBus does not move messages across the network.

Publisher Missing from Graph

1. Enable diagnostics in SignalBus Runtime Controls.
2. Select the correct context.
3. Clear retained history in SignalBus Runtime Controls if needed.
4. Trigger the publisher once.
5. Confirm a publish event appears in Event History.
6. Refresh the graph.

Publishers are observed, not registered.

Payload Appears Wrong

1. Inspect the payload type in Event History.
2. Compare it with the subscriber’s expected struct.
3. Confirm exact type identity.
4. Check whether the snapshot was truncated.
5. Confirm the Payload Policy.
6. Check whether the property is hidden.

SignalBus does not convert payload types.

Troubleshooting

No Contexts Appear

Possible causes:

• PIE is not running
• No runtime subsystem exists yet
• The Inspector has not refreshed
• PIE ended and contexts were destroyed

Start PIE and wait for the next refresh.

Event History Is Empty

Possible causes:

• Diagnostics are disabled
• No activity occurred
• Wrong context selected
• History was cleared
• PIE restarted
• Old entries were evicted

Enable diagnostics in SignalBus Runtime Controls, then trigger one known publish.

Active Subscriptions Is Empty

Possible causes:

• Subscribe code never ran
• Wrong context selected
• Listener was destroyed
• Manual unsubscribe ran
• Auto-unsubscribe occurred

Check listener lifecycle and subscription timing.

Pending Queue Is Always Empty

Possible explanations:

• Only Immediate publish is used
• Queued messages process between refreshes
• Wrong context selected
• Queue request was rejected
• Delivery completed before refresh

Use Event History to confirm enqueue and delivery.

Warning Returns After Clear Warnings

Clear Warnings removes the record, not the condition. If the condition occurs again, the warning returns.

Publisher Appears but No Subscriber Edge Exists

Check active subscriptions, scope, Message ID, payload type, lifetime, and selected context.

Subscriber Appears but No Publisher Exists

This may be normal. The listener may be waiting, diagnostics may have been disabled, or publisher history may have been cleared.

Stale-Looking Data After PIE Restart

Select the new context created by the restarted PIE session. Close and reopen the Inspector only if the context list does not recover.

Performance Notes

The Inspector refreshes periodically rather than on every SignalBus event.

For better responsiveness:

• Inspect one context at a time
• Clear history before reproducing one issue
• Avoid publishing every Tick
• Use compact payloads
• Close the Inspector when not needed
• Reduce unrelated test activity
• Use Metadata Only or Hidden when full values are unnecessary

The tool has been validated with bounded data sets including:

2,000 diagnostic events
1,000 warnings
250 graph nodes
1,000 graph edges

These limits protect editor responsiveness and do not alter runtime routing.

Safety and Data Exposure

The Inspector may expose:

• Object names
• Object paths
• Message IDs
• Payload type names
• Warning summaries
• Captured payload values when allowed

Do not place secrets in ordinary diagnostic fields. Use SignalBusHidden for sensitive properties.

Recommended Debugging Order

Use this order:

1. Context
2. Active Subscriptions
3. Event History
4. Pending Queue
5. Warnings
6. Broadcast Graph
7. Payload Viewer

This separates context, registration, execution, queueing, warning, topology, and payload problems.

Summary

The SignalBus Runtime Inspector is:

A live, read-only editor view of copied SignalBus runtime state

Always select the correct World or Game Instance context first.

Then verify:

Scope
Message ID
Exact payload type
Active subscription
Dispatch mode
Queue state
Warning state