I was clearly talking about this.
1 Like
Does streaming out happen to local parts too, or only parts streamed by the server?
My use case for preventing local parts from streaming out is:
- locally simulated distance LOD
- local arrows blocking sections of road during a race, for instance, could not be streamed by the server because they are not stored on the server. If the client streams these parts out, they will not come back when the player actually approaches them.
Thanks for finally paying some attention to streaming though.
Iāve been waiting for something like this for a while. 
Never really understood why a feature such as StreamingEnabled didnāt accommodate for unloading chunks regardless of if memory was available.
I can second this, Upon my game loading in I have 2 folders that I unload and reload.
Basically, before I push an update to my game (not yet released) we take a folder I call āStaticStreamingā
duplicate it and replace the other āStaticStreamingā folder placed in ReplicatedStorage.
When client loads it deletes the āStaticStreamingā folder in Workspace and clones the āStaticStreamingā Folder from replicated storage back into workspace, That basically removes the ability for those models to ever stream out. I had done this initially for my interaction system which I rewrote entirely a few weeks after this.
Then I have another folder for āRespectedStreamingā that basically just follows the laws of streaming for client.
28 Likes
Iām experiencing a strange bug with this new feature where a few of my players are reporting characters having loading issues; such as missing ligaments. I do use a custom R15 mesh deformation rig on the characters and have just enabled the new
StreamOutBehaviorMode a few hours ago and nothing like this has ever happened before with the standard StreamingEnabled. This is not uncommon and has occurred for alot of people randomly. The game is here. This bug is client specific and occurs seemingly randomly.
There are also a few minor weird glitches I am experiencing with RequestStreamAroundAsync.
6 Likes
THANK YOU.
This feature will be very useful in my game which has many areas full of high detail and require constant replication. This will tremendously help with both server and client performance.
4 Likes
Will locally imported parts into the workspace be streamed out now with any of these new behaviours?
If youāre looking forward, the computer does not need to render what is behind you, because you canāt see it anyway.
The same logic applies to things that are very far away. The computer will remove things that are not needed to be seen immediately.
Thereās a lot more complexity to it that what Iāve said, but that is the basic premise.
The reason we do this is so that our devices donāt lag.
Although thereās the caveat of developing to account for such a system.
For example, if you have a racing game, typically you will set up multiple check points (typically Parts) along the track to note who is in the lead.
The problem is if those checkpoints are too far away or out of vision they can be deleted until theyāre within the players vision again.
This causes problems on a scripting level as some have mentioned here that devs need to account due.
The benefit is that lower end devices such as phones can play larger games.
2 Likes
This is neat. But can we please get a way to let us prevent certain parts or models/folders from streaming out? Until we have finer control like manually loading and unloading parts and also being able to blacklist parts, itās not really that usable for me.
Unless Iām mistaken, none of these features currently exist or are planned.
I sincerely hope that Roblox will take care of this as it would finally allow me and many other cautious developers to use this feature to enhance performance.
8 Likes
Already have it live in all my experiences and it seems to be working great! Definitely a feature I have been waiting for!
1 Like
Local parts will never be streamed out, unless they have remote parts as ancestors. See:
āAny part created locally (created by a LocalScript and not replicated to the server) is exempt from stream out unless itās a descendant of a part that exists on the server.ā
8 Likes
This is a great step to helping games being more optimised for playerās with low end PCās, would be amazing to see more features in the future with streaming enabled. As well as more options for helping developers optimise their games, as we all know Roblox has its limits. Thank you for this update!
1 Like
The shooting should be calculated in the server, which is not affected by Streaming.
1 Like
I would love to see this feature aswell! In the meantime, there are ways around it. Iād recommend checking Knitās Component library out!
1 Like
allright thatās pretty poggers, I think this will definitely help in my game that has a ton of parts I can now stream out - Before I was using my own kinda bootleg render distance system because streaming would almost never de-load things that were potentially laggy unless it was literally running out of memory. This should be plenty aggro
2 Likes
Would be much appreciated if we could get more info about these planned features you mention sooner rather than later, so that we can plan and provide feedback. I take advantage of the current behavior for my game, and hearing that it will be removed without knowing what the new features actually are is a little bit worrying (though I do expect the new tools will probably be sufficient for what I need.)
To give more info, my use case of the current system is the following: Most of my game has a fog system and you canāt see very far around your character, so I donāt need or want a large TargetRadius - however I do have a few areas where there is no fog and I want the player to be able to see into the distance quite far. Currently I use RequestStreamAroundAsync and Player.ReplicationFocus to force load in the areas that are far from the player / outside of the TargetRadius, then I place the player in their intended location (which is farther than the StreamingTargetRadius from the preloaded spots) and the result is that the player gets to see the whole area at once (assuming they have the memory for it.)
A feature to dynamically change the StreamingTargetRadius on a per-player basis, or a way to tell the system ākeep these areas loaded in even if the player isnāt within radiusā (memory allowing) would probably be the simplest ways to solve my particular use case.
One other thing to note is that I do find it convenient in general that areas donāt unload if you have the memory to keep them. Specifically, my game is very part-dense and when a player teleports into a new area there is a small timeframe of noticeable lag while the new area loads. If the player was just at that place and returns to it, however, there is no lag as it is still loaded. Assuming that my player has the memory, Iām not sure why I would ever want it unloaded (though maybe areas that have been loaded previously load quicker than those that are loading for the first time, anyways? Iām not too sure on that as Iāve never tested / compared.)
Hopefully these things can be taken into account. Iām glad to see Streaming get more features! 
7 Likes
I havenāt seen any parts that was streamed out from my game yet even though I turned on the options and those parts were out of range.
Very cool! I will have to test this feature out.
This is a fantastic update, something Iāve been waiting on for a very long time! However, I do feel the LowMemory behaviour should be kept since removing that may break a lot of experiences, and some devs may not want to put strain on load times (also, choice is a good thing).
But your particular use-case is undefined, right? Memory pressure can kick in and stream things out at any moment.
In general, expecting streaming NOT to stream out for any reason before this update was an incorrect assumption because you always had players joining with devices that would force stream out. All this change does is make this behavior more consistent so that you can actually develop and test a consistent behavior accordingly.
1 Like