Do fully anchored part collections with constraints qualify for this atomic streaming behaviour? Or only root-anchored and unanchored?
1 Like
Anchored parts are always their own assembly root, however multiple anchored parts connected together via welds or constraints are considered part of the same mechanism.
So, AFAICT, after this update, if all parts in your map are welded together the entire map will be streamed in at once and kept around until the player has entirely left the map.
2 Likes
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?
I do not expect that to be addressed by this change. However, we are aware of this issue and hope to have some good news for you on that front in the coming weeks.
3 Likes
For parts that are welded to an anchored part this change will only stream the instances needed to link the part to the anchored root. But this behavior could change in the future, so I would not rely on exactly which subset of the anchored mechanism will be streamed in this situation.
1 Like
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:
- 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?
1 Like
Any plans for InstanceStreamedIn/InstanceStreamedOut signals?
6 Likes
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.
1 Like
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.
1 Like
This change has now been enabled in Studio.
1 Like
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.
1 Like
Next up, Culling Service please? - Only visually render what is in the field of vision of the camera for optimization.
4 Likes
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?
1 Like
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.
1 Like