Changes to PartInstance Streaming with Streaming Enabled

We will be soon rolling out a change to Streaming Enabled that improves how we stream parts that are grouped together into mechanisms and assemblies, such as vehicles and character models.

With traditional streaming, a part connected to other parts via constraints could be sent independently of the connected parts, resulting in incomplete physics assemblies on the client. For example, the tire of a car that is closer to the player could be sent before the chassis and the rest of the car. Or limbs of an avatar could be streamed but not the rest of the character.

To address this we are changing streaming rules to ensure that if one part of an assembly needs to be streamed that the rest of the parts in the assembly, and their joints and attachments, are also streamed at that time. This helps ensure consistent physics updates are seen on clients, and that we don’t have orphaned parts in the world that don’t update properly.

For some additional details on assemblies and special rules for anchored parts please see this post: Understanding Assemblies

It is possible to have complex moving structures like vehicles made up of multiple assemblies. This change ensures that for moving mechanisms with multiple assemblies that all components making up the mechanism are streamed when needed on the client. When any part is streamed to the client then the rest of the instances needed are also sent. Similarly, for the client-side stream out, we avoid removing any part of the mechanism until it is safe to remove all parts of the mechanism. These changes help ensure that we don’t have partial mechanisms or orphaned parts during stream in or stream out.

This change to streaming enabled is also a prerequisite for us to enable opportunistic stream out so that vehicles and other complex structures can be streamed in and out appropriately. Opportunistic stream out can give large performance boosts for very large places since the client can discard unnecessary game instances.

See also: Stream Out Behavior: New Property for Streaming Enabled

Timing Change

One important side effect of this change that developers may need to be aware of and adjust scripting for is that there may be a slight delay (10s of milliseconds) from when a part is created or enters a streamed region and when it gets sent to clients. Some situations this timing change could impact include:

  • Local script makes a remote function call to the server to create a part. When the remote call returns on the client the part may not yet exist, even though the part is close to the client focus and in a streamed area.
  • A character model is changed on the server and an event is sent to a client. Just because the client receives the event isn’t a guarantee that all the changes to the model have been streamed to the client.
  • A part moves on the server and the motion triggers an event on the client. If the part wasn’t streamed to the client before the motion there is no guarantee that it will be streamed by the time the event fires, even though it moves close to the client before the event.

Note that for all of these situations if the part happened to be far away from the client instead of nearby then there has always been similar behavior where the part would exist on the server but not yet be present on the client.

Developers may need to use WaitForChild and other techniques in these situations rather than assuming that events and property updates always occur at the same time as part streaming.

Additional notes about change:

  • We treat assemblies with anchored parts slightly differently from assemblies with only unanchored parts. If an assembly consists of only unanchored parts then the entire assembly will be sent as an atomic unit. For assemblies with an anchored root, only parts/attachments/constraints needed to link streamed parts to the root will be sent together.
  • Avoid creating moving assemblies with very large numbers of instances unnecessarily. Since we will send all the instances together if any part is near the client focus this can result in network/CPU spikes.


We intend to enable this feature globally on March 14th to give developers time to develop workarounds for the timing changes if needed. We plan to enable it in Studio on March 7th so developers can test the new behavior and implement workarounds if needed. If you think enabling this feature in this timeframe would place an unreasonable burden on you as a developer please let us know which aspect is problematic and what it would take for you to work around the change.


This topic was automatically opened after 10 minutes.

Right now I perform targeted replication to clients by cloning it on the server, parenting it to the player’s gui, and then have the client clone it from the gui and use it elsewhere. Do you anticipate any interference with that?

Also are we likely to see any more convenient ways to do less hacky targeted replication? For complicated games, its simply not memory efficient to use replicated storage


I don’t anticipate that these changes would cause any interference to your targeted replication method. Instances cloned on the client are considered local instances and are not normally subject to stream out, unless they are have ancestors that are remote parts.

We are working on better ways to have more targeted/controlled replication, but we don’t have anything to announce currently.


Will this also work with Stream Out Behavior: New Property for Streaming Enabled for whenever that gets re-enabled?

1 Like

Yes, this change is a prerequisite for the stream out change.


Is there a way to enable these changes in advance? It is not feasible for me to find everywhere in my game where this might be a problem.


Is there a timeline for the improved stream out behavior being reenabled? It was a game changer for my experiences for the day or so we were able to use it, it solved a massive amount of our performance issues.


In general, I wouldn’t expect this to be a problem for 99% of people. In fact we had this update enabled for 3 hours globally until we saw this post: Streaming Behavior Changed

The use-case is not a common pattern in games, from my understanding. Basically it requires you to have a Local Script that triggers a server Remote Function that spawns an object and IMMEDIATELY returns it. This script was expecting the instance to be available immediately on the Client after the remote function triggered. This wasn’t 100% responsive to begin with because it depended on whether the part was spawned inside of an already streamed in region or not.

We can possibly enable this in Studio to let people test locally in Start Server + Player.

The intent would be to let this change stabilize for a week or so and then immediately re-enable Stream Out Behavior.


Would appreciate some way to test it in studio. If it’s a flag to be enabled, are we able to force enable it locally somehow?


We will enable this change in Studio on March 7 to give people time to test and work around.


Thanks! I’m reasonably sure in that case that I will be mostly unaffected. Some third party code I’m using does return new parts immediately though so I would appreciate a way to test this, even if it’s just being told which flags to enable so I can do it myself.

As @CorvusCoraxx mentioned, we will enable the code in Studio so that people can test on Start Server + Player without negatively impacting their live games.

We are willing to extend our timeline IF there are pressing issues/difficulties with working around this, however we want to make sure its for cases that warrant it.

We will update here once it is enabled in Studio for testing!


Hello, this change definitely sounds like something I’ve been needing actually, and I’m wondering if there’d be any way that this could be (by developer choice) enabled in live games sooner than March 14th. My games should be fully compatible with this, and if not, I should be able to work out any bugs within the day. Stream-out is extremely important to me, seeing as the games I work on tend to be huge, and devices with less RAM tend to suffer.

1 Like

This is going to make moving Jailbreak to StreamingEnabled so much easier. Still a mighty task but helpful for sure. Thank you!


In the future, will there be a way to keep things like the game map always loaded while entities (players, detailed structures, etc) stream in and out as normal?


I’ve been having some issues in a game I work on where parts that are supposed to be deleted do not actually delete and remain for a client because it was streamed out and back in. Does this update address this issue?

Can you create a new post/bug report for the issue with part deletion you are seeing? We need more details on what is occurring, and a repro place if possible. My hunch is that this change will not address your issue.

1 Like

I can’t report bugs in the bug report category because the button is deactivated. Is there another way I can report this bug?

1 Like

Does this mean that the endorsed vehicles will finally not become a big blurry PS1 mess for a few frames when you enter them with StreamingEnabled?

We do indeed really need this. I’m currently working on an open world game with tons of skyscrapers, and currently when they’re not streamed in, they look like Wiimotes.