cable_splitter_device: Routing Signal Flow in UEFN

Overview

In UEFN's Patchwork system, a cable_splitter_device sits between a signal source and multiple receivers. While its in-editor wiring handles the static layout, Verse lets you toggle the entire splitter on or off at runtime:

• Enable() — activates the splitter so signals flow through to all connected outputs.
• Disable() — deactivates the splitter, blocking all outgoing signals even if the source is still transmitting.

When to reach for it: Use cable_splitter_device when you need a single upstream event (a button press, a timer tick, a trigger) to fan out to several devices, and you want Verse to decide when that fan-out is allowed. A classic example: a vault puzzle where the door mechanism only becomes live after the player collects all three key fragments.

API Reference

cable_splitter_device

Full public surface, resolved verbatim from the live Epic digest (Fortnite.digest.verse). Inherited members are merged from patchwork_device.

cable_splitter_device<public> := class<concrete><final>(patchwork_device):

Methods (call these to make the device act):

Walkthrough

Scenario: Three-Fragment Vault Puzzle

The player must collect three collectible items before the vault door mechanism activates. A button_device is wired (in-editor via Patchwork) through a cable_splitter_device to a door_device and a vfx_spawner_device. The splitter starts disabled — pressing the button does nothing until all fragments are collected. Once the third fragment is picked up, Verse calls Enable() on the splitter, and the button press now fans out to both the door and the VFX simultaneously.

using { /Fortnite.com/Devices }
using { /Fortnite.com/Devices/Patchwork }
using { /Verse.org/Simulation }
using { /Fortnite.com/Playspaces }

# vault_puzzle_manager — place this device in your UEFN level.
# Wire (in Patchwork): Button -> CableSplitter -> Door + VFX spawner.
# The splitter starts Disabled in its device settings.
vault_puzzle_manager := class(creative_device):

    # The cable splitter that fans the button signal out to door + VFX.
    @editable
    Splitter : cable_splitter_device = cable_splitter_device{}

    # Three trigger pads the player must step on to "collect" fragments.
    @editable
    FragmentTrigger1 : trigger_device = trigger_device{}

    @editable
    FragmentTrigger2 : trigger_device = trigger_device{}

    @editable
    FragmentTrigger3 : trigger_device = trigger_device{}

    # Track how many fragments have been collected.
    var FragmentsCollected : int = 0

    OnBegin<override>()<suspends> : void =
        # Make sure the splitter is off at the start — signals are blocked.
        Splitter.Disable()

        # Subscribe to each fragment trigger.
        FragmentTrigger1.TriggeredEvent.Subscribe(OnFragmentCollected)
        FragmentTrigger2.TriggeredEvent.Subscribe(OnFragmentCollected)
        FragmentTrigger3.TriggeredEvent.Subscribe(OnFragmentCollected)

    # Called whenever any fragment trigger fires.
    # TriggeredEvent sends ?agent, so we accept that signature.
    OnFragmentCollected(Agent : ?agent) : void =
        set FragmentsCollected = FragmentsCollected + 1

        if (FragmentsCollected >= 3):
            # All fragments collected — open the signal path.
            # Now the in-editor button press will fan out through the splitter.
            Splitter.Enable()

Line-by-line breakdown:

Common patterns

Pattern 1 — Timed Signal Window

Enable the splitter for exactly 10 seconds, then disable it again. Useful for a timed bonus round where a single button fans out to multiple reward dispensers, but only during the window.

using { /Fortnite.com/Devices }
using { /Fortnite.com/Devices/Patchwork }
using { /Verse.org/Simulation }

timed_signal_window := class(creative_device):

    # Splitter that fans one button to several reward dispensers.
    @editable
    Splitter : cable_splitter_device = cable_splitter_device{}

    # A trigger that starts the timed window (e.g. player steps on a pad).
    @editable
    StartTrigger : trigger_device = trigger_device{}

    OnBegin<override>()<suspends> : void =
        Splitter.Disable()
        StartTrigger.TriggeredEvent.Subscribe(OnWindowStart)

    OnWindowStart(Agent : ?agent) : void =
        # Open the signal path.
        Splitter.Enable()
        # Spin off a coroutine to close it after 10 seconds.
        spawn { CloseWindowAfterDelay() }

    CloseWindowAfterDelay()<suspends> : void =
        # Wait 10 seconds, then shut the splitter down.
        Sleep(10.0)
        Splitter.Disable()

Pattern 2 — Phase-Based Encounter

In a multi-phase boss fight, the splitter routes the boss's defeat signal to different downstream devices depending on the current phase. Between phases, the splitter is disabled so stray signals don't leak.

using { /Fortnite.com/Devices }
using { /Fortnite.com/Devices/Patchwork }
using { /Verse.org/Simulation }

phase_encounter_manager := class(creative_device):

    # Splitter active only during Phase 2 — routes defeat signal to
    # the final door and a cinematic trigger.
    @editable
    Phase2Splitter : cable_splitter_device = cable_splitter_device{}

    # Trigger fired when Phase 1 ends (wired from a boss health device, etc.).
    @editable
    Phase1EndTrigger : trigger_device = trigger_device{}

    # Trigger fired when Phase 2 ends.
    @editable
    Phase2EndTrigger : trigger_device = trigger_device{}

    OnBegin<override>()<suspends> : void =
        # Phase 2 splitter is inactive until Phase 1 is cleared.
        Phase2Splitter.Disable()

        Phase1EndTrigger.TriggeredEvent.Subscribe(OnPhase1End)
        Phase2EndTrigger.TriggeredEvent.Subscribe(OnPhase2End)

    OnPhase1End(Agent : ?agent) : void =
        # Phase 1 cleared — arm the Phase 2 signal path.
        Phase2Splitter.Enable()

    OnPhase2End(Agent : ?agent) : void =
        # Phase 2 cleared — disarm so no further signals leak.
        Phase2Splitter.Disable()

Pattern 3 — Player-Count Gate

Only enable the splitter (and therefore the downstream devices) when enough players are present. This prevents a solo player from accidentally triggering a co-op mechanism.

using { /Fortnite.com/Devices }
using { /Fortnite.com/Devices/Patchwork }
using { /Verse.org/Simulation }
using { /Fortnite.com/Playspaces }

player_count_gate := class(creative_device):

    # Splitter that routes a co-op button to two pressure-plate devices.
    @editable
    CoopSplitter : cable_splitter_device = cable_splitter_device{}

    # Minimum players required for the mechanism to be live.
    @editable
    RequiredPlayers : int = 2

    OnBegin<override>()<suspends> : void =
        CoopSplitter.Disable()

        # Re-evaluate whenever a player joins or leaves.
        Playspace := GetPlayspace()
        Playspace.PlayerAddedEvent().Subscribe(OnRosterChange)
        Playspace.PlayerRemovedEvent().Subscribe(OnRosterChange)

    OnRosterChange(Player : player) : void =
        Playspace := GetPlayspace()
        Players := Playspace.GetPlayers()
        PlayerCount := Players.Length

        if (PlayerCount >= RequiredPlayers):
            CoopSplitter.Enable()
        else:
            CoopSplitter.Disable()

Gotchas

1. cable_splitter_device inherits from patchwork_device, not creative_device

You must import using { /Fortnite.com/Devices/Patchwork } in addition to using { /Fortnite.com/Devices }. Without the Patchwork import, the compiler reports cable_splitter_device as an unknown identifier.

2. Always declare it as an @editable field

You cannot construct a cable_splitter_device in Verse code — it must be a placed instance from the UEFN level. Declare it as:

@editable
MySplitter : cable_splitter_device = cable_splitter_device{}

Then drag-assign the placed actor in the UEFN details panel. A bare cable_splitter_device.Enable() with no instance will not compile.

3. Editor default state matters

The splitter's Enabled/Disabled state in the editor is its starting state at runtime. Calling Splitter.Disable() in OnBegin is the safest way to guarantee a known starting state regardless of what the editor setting is.

4. Enable/Disable affect the whole splitter, not individual outputs

These methods toggle the entire device. If you need selective per-output routing, use multiple splitters (one per output group) and enable/disable each independently.

5. No events on cable_splitter_device

The device exposes no events — it is a purely imperative device. You cannot subscribe to it to know when a signal passes through. If you need to react to a signal, subscribe to the downstream device's event instead.

6. Sleep requires a <suspends> context

If you call Sleep(10.0) (as in Pattern 1), the function must be marked <suspends> and called via spawn { } from a non-suspending context. Calling it directly from an event handler (which is not suspending) will fail to compile.