Widget-first vs Multi-HUD

The plugin offers two mount paths. Both share the same Subsystem registry, so events route the same way regardless of how the layer was created.

Decision matrix

Use this when	Path	What to use
One HUD per screen, designer wants full Slate control around it	Widget-first	WBP_WebHUD (Widget Blueprint child of WebHUDWidget)
Multiple HUDs at independent screen anchors, you want one node per HUD	Multi-HUD	Add Web HUD Blueprint node
Want both at once	Both	They share the same Subsystem registry — works fine

Widget-first

Use a Widget Blueprint child of WebHUDWidget. You get the full UMG canvas around it — composite Slate borders, animations, and other UMG widgets on top.

Event BeginPlay
  └─ Create Widget (Class: WBP_MyHUD)
        └─ Add to Viewport

TIP

Set the URL on the widget's Class Defaults. The CEF browser starts loading the moment the widget is constructed.

Multi-HUD

One Blueprint node per HUD. Each call registers a named layer at a screen anchor with a normalized size.

Event BeginPlay
  ├─ Add Web HUD ("HpBar",   "http://localhost:5173/hp",     TopLeft,      (16,16), (0.25, 0.12))
  ├─ Add Web HUD ("Skills",  "http://localhost:5173/skills", BottomCenter, (0,32),  (0.50, 0.18))
  └─ Add Web HUD ("Minimap", "http://localhost:5173/minimap",TopRight,     (16,16), (0.18, 0.18))

Each Name becomes the layer's BridgeName for routing.

Routing rules

When a ReactBridgeSender pushes data:

• If TargetBridgeName matches a HUD's Name / BridgeName, only that HUD receives.
• If TargetBridgeName is empty, all HUDs receive (broadcast).

This applies identically to both mount paths. A widget-first WBP_WebHUD and a multi-HUD layer with the same BridgeName are indistinguishable to the Sender.

See Multi-HUD for anchor reference, z-order, and per-layer visibility.