Remotes

This module is internal. It is documented so you can reason about how Flux behaves and performs, but it is not re-exported from the root Flux module and its surface may change without notice. For everyday use, reach for Flux.Server and Flux.Client.

local Remotes = require(ReplicatedStorage.Flux.Utils.Remotes)

The smallest module in Flux. It finds or creates the two remote instances every event travels over, and caches them.

RemoteGroup

export type RemoteGroup = {
	Reliable: RemoteEvent,
	Unreliable: UnreliableRemoteEvent,
}

RemoteEvent

Named Flux_Reliable. Carries Fire, FireAll, and all invoke traffic.

UnreliableRemoteEvent

Named Flux_Unreliable. Carries FireUnreliable and FireAllUnreliable.

Remotes.Get()

function Remotes.Get(): RemoteGroup

Resolves both remotes with WaitForChild, caches the group, and returns it.

Yields until both instances exist. Called by the client through Bridge.Initialize, so the first Flux.Client(...) call on a client blocks until the server has created them.If no server code ever calls Flux.Server(...), this waits forever and every client hangs. See Installation.

Remotes.Create()

function Remotes.Create(): RemoteGroup

Finds each remote with FindFirstChild and creates any that is missing, then caches and returns the group. Non-yielding and idempotent. Called by the server through Bridge.Initialize.

if not reliable then
	reliable = Instance.new("RemoteEvent")
	reliable.Name = RELIABLE_NAME
	reliable.Parent = script
end

Both functions share one _cachedGroup, so whichever runs first wins and the other returns the cache. Only one context ever calls each in practice.

Where the remotes live

Remotes (the ModuleScript)

Flux_Reliable (RemoteEvent)

Flux_Unreliable (UnreliableRemoteEvent)

The remotes are parented to the Remotes ModuleScript itself, which is script inside the module, not to a folder. That is why the module needs no path configuration: it looks for its own children.One side effect is that the instance tree in Studio shows two remotes nested under a ModuleScript, which looks unusual but is intentional.

Constants

Constant	Value
`RELIABLE_NAME`	`"Flux_Reliable"`
`UNRELIABLE_NAME`	`"Flux_Unreliable"`

Renaming these instances at runtime breaks resolution. Remotes.Create would create a fresh pair alongside the renamed ones, and the two sides would end up on different remotes. Leave them alone.

Two remotes for the whole game

However many events you declare, Flux creates exactly these two instances. The event name travels inside the payload as a length-prefixed string, and the receiving dispatcher uses it to find listeners.

Raw remotes
Flux

Remotes/
  Chat            (RemoteEvent)
  Damage          (RemoteEvent)
  Purchase        (RemoteFunction)
  Position        (UnreliableRemoteEvent)
  ... one per message type

Flux/Utils/Remotes/
  Flux_Reliable     (RemoteEvent)
  Flux_Unreliable   (UnreliableRemoteEvent)

There is no RemoteFunction anywhere in Flux. Invocations are request and response packets over Flux_Reliable, which is why they can be concurrent, why they carry an explicit request id, and why the timeout is Flux’s own 60 seconds rather than the engine’s behaviour.

Entry Point

Classes

Namespaces

Internals

RemoteGroup

Remotes.Get()

Remotes.Create()

Where the remotes live

Constants

Two remotes for the whole game

Next steps

Bridge

Architecture

​RemoteGroup

​Remotes.Get()

​Remotes.Create()

​Where the remotes live

​Constants

​Two remotes for the whole game

​Next steps

Bridge

Architecture

RemoteGroup

Remotes.Get()

Remotes.Create()

Where the remotes live

Constants

Two remotes for the whole game

Next steps