Portals
A Portal is a named jump target you can reach from C# code by ID, without drawing a wire from every possible screen to it. It's the escape hatch for navigation that doesn't come from a button on the current screen.
What Portals are for
- Returning to the Main Menu from deep inside a settings flow, without wiring every sub-screen back to it directly.
- Navigation triggered by non-button events: a timer expiring, a network callback, a cutscene ending.
- Any case where the thing that decides to navigate is code, not a wire on the Graph.
Authoring a Portal
- In the Flow Editor, right-click the canvas and choose Create Node > Flow > Portal Trigger.
- The node has a text field labeled "Trigger ID". Set it to whatever string you'll call from code, e.g.
"ToMainMenu". - It has exactly one output port, named
"Next". Wire that to the target screen's"In"port (or to an Application Quit node).
Invoking a Portal from code
HookUIManager.Trigger("ToMainMenu");
Full signature:
public static void Trigger(string triggerID)
It's a static method on HookUIManager — you don't need a reference to the manager instance to call it.
Internally, Trigger looks up the first PortalNodeData in the active flow graph whose TriggerID matches the string you passed, and follows its wire:
- If the wire leads to a Screen node,
HookUIManagertransitions to it exactly like a normal button-driven transition — the sameHide()/Show()calls run. - If the wire leads to a Quit node, the app quits (or Play Mode stops, in the Editor).
Portals and the back-stack
Triggering a Portal to a Screen node does push the current screen onto the navigation history, same as a normal wired transition. So a Back button pressed after a Portal jump correctly returns to wherever the user was before the jump.
What Portals are NOT
A common misconception: Portals are not triggered implicitly by a button whose ID happens to match the Trigger ID. There is no automatic scanning of Portal nodes by button ID.
A button only navigates in one of two ways:
- A direct wire from its own screen node's output port, or
- An explicit call to
HookUIManager.Trigger(...)— from that button'sOnClickUnityEvent (wired to a small script), or from any other C# code.
Minimal example
Instead of wiring every settings sub-screen back to Main Menu directly, give one button a wrapper method that calls the Portal:
public class SettingsFlow_QuitToMenu : MonoBehaviour
{
public void OnClick()
{
HookUIManager.Trigger("ToMainMenu");
}
}
Wire that method to the button's OnClick UnityEvent, and every settings sub-screen can share the same "return to menu" Portal instead of needing its own direct connection.