Skip to content

StreamingEnabled

Instance streaming is supported because every system that decides anything runs on the server, which always sees the whole world. Streaming only affects client presentation.

ChloeKernel supports instance streaming. The architecture is server-authoritative, and the server always has the full world whatever each client has streamed in. Every system that decides an outcome runs on the server and never reads a client’s copy of the map: Zones sweeps, Replica interest, NPC senses and pathfinding, anti-exploit, kit validation, MoveKit’s server ground probe, and hit detection through Rewind. Server code needs no changes for streaming.

Streaming changes what exists on a client, so it only affects client presentation and the few server actions that move a player somewhere their client has not loaded.

  • InteractionKit creates prompts on the server under tagged instances in Workspace, so a prompt streams in and out with its part. Every trigger re-validates distance, line of sight and cooldown on the server either way.
  • Mounts and TagWatch follow CollectionService tag signals live. On a streaming client, what streams in mounts and what streams out runs its cleanup. Only instances under the root (Workspace by default; the client ComponentController also mounts in the local PlayerGui) count, so tagged templates in storage stay inert.
  • ProjectileClient, AudioKit emitters and RagdollClient work from wire data, pooled local parts and the player’s own character. None of them depends on streamed world geometry.
  • BonePhysics binds bones on models the client can see. The engine documents only the local player’s own character as the replication focus, so do not assume other players’ characters stay streamed in, and rebind their chains when they stream back. For NPC or prop rigs a client binds chains on, set ModelStreamingMode = Persistent or rebind on stream-in: a model that streams out mid-simulation takes its bones with it. HairKit’s client manager watches CharacterAdded and the accessories that stream into a character afterwards, and settles each character with one scheduler deadline.
  • Highlights keeps a request per adornee until the adornee is destroyed or removed. An adornee that streams out without being destroyed keeps its request, so call remove for it.
  • NPC models may stream out on distant clients while their server brains keep acting. That is cosmetic: hits, hearing and pathfinding never depended on the client copy.

Move players on the server with Movement.teleport(kernel, player, cframe, options?). In its own thread it calls player:RequestStreamAroundAsync(cframe.Position, StreamTimeout) (default 5 seconds; 0 skips the request), then, if the same character is still in the world, publishes AntiExploit.Forgive so the Movement Monitor does not rubberband the move, and pivots the character. Without the stream request, a streaming client can land somewhere it has not loaded and stall. Stages is a different thing despite the name: it loads and unloads gameplay content by zone occupancy on the server and does not touch Roblox streaming.

local Movement = require(game:GetService("ServerScriptService").ChloeKernelServer.AntiExploit.Movement)
-- Returns at once; the pivot happens after the destination streams in (or 2 s pass)
Movement.teleport(Kernel, Player, workspace.Arena.Spawn.CFrame, { StreamTimeout = 2 })

For moves that must not wait (knockback), publish AntiExploit.Forgive for the player and write the CFrame yourself.

Anything your client code holds a long-lived reference to (BonePhysics binds, custom visuals attached to world models) should be Persistent, or rebound when it streams back in. A client-side TagWatch.watch added callback, or a client component under Mounts, is the natural place: it runs again each time the tagged model streams in, and its removed callback or cleanup runs when it streams out.

ChloeKernel v0.9.1. Access to the framework is private and granted individually by Chloe. Games built with it credit CryptedChloes in their description.