Big Changes to StreamingEnabled

Hey developers,

Some of the top feature requests we’ve gotten have been improvements to the way StreamingEnabled works and the amount of control that developers have over the feature in their own games. Well, you asked and we listened. We’ve made several improvements to StreamingEnabled to give developers more control and to improve gameplay in situations where players are experiencing poor network conditions. The main advantages of StreamingEnabled remain the same and recent improvements help address some of its challenges.


  • Faster load times: players can join a game and start playing without needing to wait for the entire place to be loaded.
  • More complex places: many more parts and larger places can be created
  • Support more devices: lower memory usage means games can be played even on devices without sufficient memory to store the entire place.


  • Clients on poor networks may be able to enter regions before they have been streamed in from the server. This can be mitigated using Streaming Pause Mode, as described below.
  • Clients usually will not have the entire Workspace available locally. Developers must ensure that game functionality works when clients are missing parts of the world, such as by using Instance:WaitForChild (Please be aware that there is a chance WaitForChild will hang forever if the instance being waited for is never streamed in and that a timeout in WaitForChild is not specified).

API Additions:

Workspace.StreamingMinRadius (not scriptable)

The minimum radius property controls the minimum area around the player’s current replication focus that will always be sent with high priority. When a player no longer has the minimum radius around them, as a result of moving or CFraming to a new location, regions within the minimum radius will be sent first.

Care should be taken when increasing the minimum radius as this will result in more server time and bandwidth dedicated to streaming at the expense of other components. Avoid setting the minimum radius larger than needed to ensure the desired gameplay experience. Large values can also result in more time spent in streaming pause, leading to a player frustration. Avoid setting the minimum radius larger than the size of the world.

Workspace.StreamingTargetRadius (not scriptable)

Target radius properties control how far away from the player’s current replication focus where terrain and instances will be streamed to the player. Once terrain and instances within this target distance have been sent no additional terrain or instances will be streamed until that condition is no longer met. Note that clients may have more than the target radius available since as the player changes location previously streamed areas are only removed if the client has insufficient memory. As a result clients will continue building up a more complete subset of the place as they move around, memory permitting.

The target radius should be greater than the minimum radius. If the target is less than the minimum, then the minimum radius will be used as the target. Avoid setting the target radius equal to the minimum radius because this will prevent any additional areas beyond the minimum radius from being streamed in. As the player moves, this will result in the minimum needing to be sent repeatedly, possibly resulting in streaming pauses. Larger target radii result in more server time spent searching for instances and regions to stream; so care should be taken when increasing the target radius, especially for games with larger numbers of players per server.

Radius Notes

While these values are specified in units of studs, internally we search by predetermined increments, which is currently 64 studs at the time of this posting. So attempting to set fine stud level control will have no effect since it is effectively quantized to multiples of 64 during the region sweeping.

The search for unsent regions is performed in a rectilinear manner, not spherical as the name radius would imply. When the server is checking for regions in radius ‘r’ it will search from (-r, -r, -r) to (r, r, r).

Workspace.StreamingPauseMode (not scriptable)

Streaming pause is a new feature developers can use to prevent some challenges that arise when clients haven’t yet received regions. Developers can choose to have players in streaming enabled games pause when the minimum radius is not present around the player’s replication focus or the player’s character. The pause is a client-side physics pause, preventing the player’s character from moving and parts which the client owns from simulating. Only physics for parts that are owned by the player are paused. Networking and scripting is unaffected. Since scripting is not interrupted and scripts can query the pause state (Player.GameplayPaused) developers can alter gameplay and/or trigger UI for paused players if desired.

Local script CFraming of the player is more likely to cause streaming pause events because the player will be moved before the server has the chance to send regions around the new location. To avoid this server CFraming is preferred.

By default, a Roblox dialog is shown on the screen. This dialog informs the player that the game is currently paused while content is streamed in. Developers can disable this GUI via GuiService:SetGameplayPausedNotificationEnabled.

Players can also enter the paused state even when the minimum radius is present when the replication focus has been set away from the player’s character and the character enters a non-streamed region. Care should be taken when streaming pause is used in combination with setting the replication focus away from the player since streaming will occur around the focus, not the character. This can result in a player being paused but never unpausing since the region containing the player will not be sent if it is outside the target radius around the replication focus.

Player.GameplayPaused (read only)

This property indicates the player’s current pause state. Note that since the pause determination is made by the client the server could experience delay in seeing the current pause state, particularly if poor network conditions caused the pause in the first place.

GuiService:SetGameplayPausedNotificationEnabled(bool enabled)

This method allows developers to disable the built-in notification when a players gameplay is paused. They can then add in their own UI if they wish to customize it.

bool GuiService:GetGameplayPausedNotificationEnabled

Returns whether or not the notification has been disabled by the developer.

Engine Improvements:

We’ve improved how servers search for regions to be sent to clients, resulting in quicker streaming while using less time. We have made improvements to physics simulation to ensure that clients don’t simulate parts that overlap regions that aren’t streamed in on the client. Streaming enabled games will load faster and clients will receive streamed in regions more quickly than in the past.

We’re super excited to share these features with you! We look forward to seeing how the new-and-improved StreamingEnabled gets used.

Developer Relations


Let’s take it slow, everyone! The topic will be open for discussion in 15 minutes, gotta be sure you had time to read the announcement :stuck_out_tongue:


This topic was automatically opened after 18 minutes.

It’s great to see streaming getting some love. Unfortunately, I still can’t use this feature because we can’t explicitly define what gets streamed in together. Having only certain parts of a model streamed in just isn’t useful in a lot of cases, and it makes code way harder to write because of the lack of guarantees. We need some way to mark a model as being an atomic unit, that is, every child object of that model is present on the client or none of it is.


Rather nice to see some updates to StreamingEnabled. It feels like everything from it’s introduction back in 2013’s Witching Hour event to modern games like Vesteria have shown it wasn’t very viable before, but it still felt like an idea which was viable for sprawling open worlds.

Since the focus of StreamingEnabled is more based on a general radius around the player, I must ask. Is there any plans to focus on more fine tuned systems to load in locations in the future, rather than a general one-size-fits-all addition like StreamingEnabled? If this works better than it did in the past, it can be a great feature, but it doesn’t look like it has enough control.

If I were to propose an example, I really like Polyhex’s suggestion of zones/scenes, which can be found here.


Happy to see this feature finally becoming developer friendly.

However, I’m not happy with the UI presented by default during a pause.

It completely pulls the player out of the game. The popup is in the dead center of the screen, fully opaque, and it’s pretty large, so it obstructs whatever the player was doing before the pause. As far as I can tell, there also isn’t any animation which would be an important UX touch to let the player know that the game is still working (which is important when they struggle with reading). Similarly, the icon (signal waves with an exclamation point) is kind of misleading, implying the user’s Internet isn’t working, when it could just be slow.

While the design is consistent with the UI for the disconnect dialog, I don’t think it’s appropriate to reuse that for this case because the disconnect dialog is intended to remove you from the game. This should be designed differently.

Even if developers can replace this UI, the grand majority of games will still use the default UI, so it should be as friendly as possible.

IMO make the UI flatter and closer to the bottom of the screen, and replace the icon with a loading spinner.


I have been hoping this gets released soon, and looks like my prayers have been answered.

I have been having issues where some mobile devices crash after playing in the game for a bit because the game uses roblox terrain as its primary “ground” so really curious if this fixes that!!

So if the player’s game is paused they’ll pretty much appear frozen for everyone else right? (cat for reference to what I mean)


I’m sure you can design your own version of the UI since they do offer a way to disable them. However, I haven’t seen an event that is in charge of firing this said UI so I wouldn’t know exactly how to implement what you speak of at the time but I’m sure there is something that lets us work with this (considering they have a way of disabling it).


The option to replace the UI is irrelevant to the issue. Default UI will still be used in the grand majority of cases, so it still matters.


I like many others was excited to see changes to streaming,

I even started going into studio trying to solve the long running problem that keeps me from using StreamingEnabled in my game.

However, Streaming is still too messy.

Along with the fact that we can’t Blacklist specific parts from EVER getting streamed in/out.
A simple boolean property on each part, “CanBeStreamed” would solve all these problems.

My example use-case is I have a large ship that is far away from the lobby, and therefore is immediately streamed out, however, it needs a PrimaryPart in order for the regeneration to the client to work properly. This breaks my script and I have to ignore StreamingEnabled for now.

I support this vision, but streaming is currently too limited, still.


I thought you meant that you wanted to replace this feature for your own projects … but I’m sure that if the developer feels this is an issue they will make sure to replace it with something else or remove it.


Excellent changes! I unfortunately like @evaera will not be transitioning as my game fundamentally relies on a few things being present, and I don’t see a way of working around this.

What would be very useful, if evaeras suggestion cannot be implemented, would just be a streaming ignore list or a way to tag instances to always be replicated regardless of proximity to the streaming region.

Thanks though!


Are these features already live or are they yet to be implemented? Next to this question I would just like to appreciate how helpful and beneficial this feature is to performance and part heavy games. Big ups to the roblox engineer team! :+1:


It’s currently live, I tried it out with my game.

Most of us still can’t use steaming because we can’t mark certain parts/models for being ignored from streaming


Would it be possible to get an explanation as to the reasoning for avoiding instance specific streaming? As far as I can tell this has been something we’ve been asking for for a while. Is something like this planned eventually? Is it difficult to implement? Or are there reasons we aren’t considering for why it shouldn’t be added? Thanks!


I understand that the UI is customizable, but I think the default could use a few minor adjustments to improve the UX.

For most players, it’s likely that they’ve seen a loading screen before, so they’d be able to react appropriately if there was at least a spinning loading icon. But on the default popup, someone who can’t read for example might interpret the popup wrong and leave the game.
Just my 2 cents lol


Streaming Pause is going to be really useful. I can see the practical benefits in large open worlds of having a pause feature, and I’ll especially be using this in my random terrain generation project. As other users have said, I’d very much like the option to customise the pause message, or better yet, have the ability to connect to a callback from the pause so we can provide our own “aesthetics” like a screen blur or similar. Just a few thoughts off the top of my head though.


This is a very welcome change and streaming enabled definitely needs the attention. I however have the same concerns as many others have voiced. I still can’t use streaming enabled due to script errors as a result of not being able to black list what models/parts do and do not get streamed. This is such an important feature. Nothing beats being able to give player faster smoother experiences while supporting as many devices as possible. I really hope to see more user friendly customization added to streaming enabled in the near future.


Is there any chance of a method in the future allowing the client to request chunks to preload so that teleporting can be made smoother?