Besides streaming, will we ever see Visible property on Models? It’s one of the most basic features of any game engine, not to mention that It would benefit developers who want to implement custom LoD. From I heard, popular experiences like Mad City have custom LoD for building interiors, and I’m sure they would benefit from this feature a lot.
99 Likes
As the author and maintainer of the networking library Red, I’ve recently started receiving a lot of help requests for sending instances over remotes due to streaming being enabled by default. It appears that when the server moves an instance into a streamable area around a player, it will not always be streamed in the same frame, resulting in that instance being networked as nil instead of the instance.
I would love if this could be fixed in streaming or if there were a way for me to fix this in my library, keep up the good work guys <3.
25 Likes
Will give this a try with my streaming project later this week. I don’t think this impacts our code, but if I find any problems I’ll let you folks know 
11 Likes
This update seems pretty helpful! I did origanally turn streaming back off my game due to it breaking many of the models and scripts. I will give it a try with this feature
12 Likes
Whichever script breaks, you can track the object referenced in that script that si being streamed out and set it to be Persistent. Thats at least how i dealt with these kind of issues in my games
14 Likes
I don’t know if this problem is also fixed now, but as far as I know, this problem still occurred in one of my experiences !
It is mainly the first part of this post
14 Likes
setting a model to persistent kinda defeats the purpose of streaming, it’ll just stay in memory and it’s better to just have it be tolerant of streaming in and out instead of a band-aid fix like that
11 Likes
Will the legacy mode ever be deprecated/eventually removed? I rely on the fact Non-Atomic models initially replicate the empty parent model to the client for referencing reasons.
Incase anyone is curious I take advantage of this fact to have a unified module script table for both the server/client that includes a direct reference to the Model along with other information. This is a really easy solution to solve ether by using a separate module script or just dynamically adding the reference on the server only but i’m lazy 
I do imagine some people have situations where its non-trivial to replace this functionality which is why I’m curious if it will ever be removed.
11 Likes
Thank you so much for this update! This hasn’t solved all of our problems with streaming enabled and memory usage from it but it’s definitely a welcome improvement.
9 Likes
I appreciate the constant improvements to streaming and the benefits it provides. I would love to utilize streaming but find it impossible to until locally created parts are simulated outside the streaming radius, which they are currently not even while in a persistent model.
Since streaming correlates to loading and unloading parts on the client, locally created parts, especially while in a persistent model, should always run physics.
10 Likes
Why can’t we just have a ReplicationService where we can manually toggle replication on individual objects, including terrain? I know exactly what I want to stream in/out and exactly what I don’t want to bother wasting bandwidth on. Streaming isn’t a toggleable ‘upgrade’, there are networking costs that come with it due to having to send large amounts of parts and voxels to potentially hundreds of players. This network impact is rarely discussed and instead streaming seems to be treated as this perfect ideal package.
21 Likes
Sounds great. FWIW, the principles of less models being sent improving join times is also why I created a custom replication system for my own experience. ReplicatedStorage has the absolute bare minimum and we manually replicate instances the client wants soon after they join. I am able to achieve 1-second join times with a codebase of 5.4K+ ModuleScripts, StreamingEnabled, Deferred SignalBehavior and a bare minimum amount of replication during the initial snapshot.
What is the behaviour of streaming out, a destruction or a nil parent? I’d like to know what the proper way to check for parts streamed out is so I can know when to cleanup lifetime objects that need to observe part descendants of the workspace. Probably the best way to check is a nil parent after AncestryChanged, though other methods like Destroy also fire it, no?
As more and more optimisation features visit developers’ gift boxes that have to do with contextual parenting by the engine, it would also be helpful to start thinking about methods to differentiate between destruction and nil parenting. This is already a pain point with our own systems and it will grow as features like this become more widely used.
Also deferred parenting sounds especially great for characters. To avoid daisy chaining waits I take advantage of replication also being reliably ordered to essentially “snapshot” an instance tree at a moment of replication. It’s unnecessary boilerplate though, and character loading events are a wick of evil old engine code that was intended to be fixed but encountered technical blockers. Deferred literally solves 99% of most deep tree access issues (hence the fancy display name). Hopefully this works even without StreamingEnabled or with Deferred SignalBehavior at the very least.
9 Likes
We recently added a clarification to streaming out in the documentation:
“When an instance streams out, it is parented to nil so that any existing Luau state will reconnect if the instance streams back in. As a result, removal signals such as ChildRemoved or DescendantRemoving fire on its parent or ancestor, but the instance itself is not destroyed in the same sense as an Instance:Destroy() call.”
Signals related to destruction do not fire on stream out.
13 Likes
I doubt Roblox will remove it, but just take that with a grain of salt since it’s likely they will unfortunatly.
5 Likes
Hoping soon we see an update that makes parts be always streamed in by default, except for the parts that we mark as safe to stream out. So essentially the opposite of what we have now. Unfortunately this is a very limiting factor for us, so we have to rely on a custom implementation for streaming.
5 Likes
Does this decrease load times for games with lets say 50 zombies in a current game? I want to increase the amount of zombies in my game while also decreasing load times/lag for lower end devices by streaming them out.
I currently use Streaming in my game that relies heavily on mesh but I can’t really test that parts/models are streamed out. Is there a way for me to test that without buying a potato? Even with min radius of 128 it still seems to load everything when I join?
Game in question if anyone can help: Valor FPS 🎃 ZOMBIES EVENT - Roblox
5 Likes
The reason why they are not streaming in and persisting is because players are having their devices crash and they are unable to play Roblox if Roblox is unable to stream out.
4 Likes
Wouldn’t it make sense to have those parts streamed out by default and only stream them in when possible?
It’s basically what we already have but without having to go through every part in the workspace and selecting persistent to get the illusion of exclusivity
3 Likes
This means that once a subtree arrives there is less need for localscripts to use WaitForChild to ensure that instances have arrived
Good!
4 Likes
Hi
So basically this new way of streaming is atomic, but without all parts of the model being loaded atomically?
Took me a while to figure out all the empty models that had default streaming were causing lag. I’m happy this is now the behavior so others won’t have to run into it.
My fix was to just put almost everything as atomic (99% of models are small, tightly packed parts).
2 Likes