What concrete conditions would qualify a part for this? Is there a way I can guarantee atomic streaming of any arbitrary group of parts I choose going forward using this new behaviour?
If not, I think it would be valuable to have this, especially for newer developers. Streaming can be time consuming to use in its current state without part collection atomicity or the ability to force certain world dependencies to always be present once streamed or when the game loads.
With this update coming soon, is it possible to increase a place maximum size for publish? Big terrain takes up quite a bit of storage though.
I suspect it would affect shooter-type games greatly TBH, and all animations that shoot events for FX which is what bothers me the most since our games are heavy on the animation events (which already have client delay).
Is streaming client dependent? As in, ping dependent?
We already have an issue with lagged animations because of issues passing the replication barrier. Adding to that might affect animations greatly.
Will be testing it tomorrow for sure in QA environment but would love to have a contact if possible for any complications.
Does this timing change apply to anchored parts as well?
My games rely on the “predictable” behavior for chunks that are already streamed to the player, but only for anchored parts.
To clarify, my games do something like this:
Will this change lead to clients not finding these expected parts all the time?
Any plans for InstanceStreamedIn/InstanceStreamedOut signals?
I would not suggest trying to leverage this change to part handling to get atomic streaming. We are working on a feature to allow developers to request that models stream atomically, but I don’t have an ETA on that feature currently.
Does this timing change apply to anchored parts as well?
My games rely on the “predictable” behavior for chunks that are already streamed to the player, but only for anchored parts.
To clarify, my games do something like this:
Server creates a Model with Parts (all Anchored), immediately calls Remote with a reference to this Model to clients. Models don’t stream in/out themselves, only the parts inside them can, so this reference always is valid as this Model is parented to the Workspace before the Remote is invoked.
Client checks if the expected parts are in the Model. If not, it “bails”, the model its contents are assumed to be far away and not in a streamed-in chunk.
If the parts are in there, the client continues on, using these parts.
Will this change lead to clients not finding these expected parts all the time?
I believe it is likely that when the remote function calls on the client that the parts may not yet exist under the model with this change. The model will exist, but the parts may not be streamed, even if they are close to the client. This sound like a scripting scenario that will need to be adjusted.
This change has now been enabled in Studio.
in dont see it in beta features
This is just enabled in Studio, it was not added as a beta feature.
If this feature should be there when it was in the past. It’s not there for me too…
I also forced updating studio but didn’t worked
There will be no visual indication in Studio that this change is active, streaming will just operate slightly differently behind the scenes.
Next up, Culling Service please? - Only visually render what is in the field of vision of the camera for optimization.
Is there a recommended process for dealing with remote functions that return parts? My specific case is a building tool that returns the new part when you create one. Is the reference returned by the remote function invalid? Is there a way to wait for this part from the reference returned by the function? Is there another robust way to find and wait for this part?
The normal recommendation is to use WaitForChild on the parent of the part in question, or use ChildAdded on the parent to be notified when children are added.
I see, this is kind of gross. I think the easiest way to do this without having to make huge changes to accommodate this is to return the parent and the name of the part, but now I need to give parts guids as names. 
It would be marginally cleaner if I could access some unique ID for the instance and wait for that. Not worth it, names will do I suppose.
So to confirm, a part instance returned by a remote function when streaming will always be an invalid reference (i.e. unreliably nil)?
Actually I retract my retraction of the earlier suggestion WRT unique IDs, this is tremendously messy that I have to use the part’s name for this to find it uniquely inside its container. I cannot provide a friendly name for the part to players now without having to refactor a ton of code or else desync the part’s name on the client, and there’s no fast way otherwise to find the part within it’s container.
I am patching around this with the following code and using it everywhere I need to pass parts from server to client, but this solution desyncs the part’s name from the server. Hopefully this will not be an issue down the road.
I think API to obtain a part’s unique ID and efficiently wait for a child/ancestor part with that ID would solve my issues.
If the part is created in the remote function then at the time the function returns on the client the part will be invalid.
We are evaluating ways to simplify things for developers writing local scripts in streaming enabled games. Thanks for your suggestion about waiting using unique IDs.
Do we have any timeline for Streaming Out yet?
Shenanigans! This new change completely streaming for my game (I have always used it). The NPC enemies do not show up at any range, sometimes even when my character is attacking them (range < 15 studs).
In this delightful moment, a rock was thrown by an invisible enemy. The rock shows up immediately (presumably because it does not have skinned mesh animations)
Turning off StreamingEnabled fixes my game.
