We will be soon rolling out a change to Streaming Enabled that improves how we stream parts that are grouped together into mechanisms and assemblies, such as vehicles and character models.
With traditional streaming, a part connected to other parts via constraints could be sent independently of the connected parts, resulting in incomplete physics assemblies on the client. For example, the tire of a car that is closer to the player could be sent before the chassis and the rest of the car. Or limbs of an avatar could be streamed but not the rest of the character.
To address this we are changing streaming rules to ensure that if one part of an assembly needs to be streamed that the rest of the parts in the assembly, and their joints and attachments, are also streamed at that time. This helps ensure consistent physics updates are seen on clients, and that we don’t have orphaned parts in the world that don’t update properly.
For some additional details on assemblies and special rules for anchored parts please see this post: Understanding Assemblies
It is possible to have complex moving structures like vehicles made up of multiple assemblies. This change ensures that for moving mechanisms with multiple assemblies that all components making up the mechanism are streamed when needed on the client. When any part is streamed to the client then the rest of the instances needed are also sent. Similarly, for the client-side stream out, we avoid removing any part of the mechanism until it is safe to remove all parts of the mechanism. These changes help ensure that we don’t have partial mechanisms or orphaned parts during stream in or stream out.
This change to streaming enabled is also a prerequisite for us to enable opportunistic stream out so that vehicles and other complex structures can be streamed in and out appropriately. Opportunistic stream out can give large performance boosts for very large places since the client can discard unnecessary game instances.
See also: Stream Out Behavior: New Property for Streaming Enabled
Timing Change
One important side effect of this change that developers may need to be aware of and adjust scripting for is that there may be a slight delay (10s of milliseconds) from when a part is created or enters a streamed region and when it gets sent to clients. Some situations this timing change could impact include:
- Local script makes a remote function call to the server to create a part. When the remote call returns on the client the part may not yet exist, even though the part is close to the client focus and in a streamed area.
- A character model is changed on the server and an event is sent to a client. Just because the client receives the event isn’t a guarantee that all the changes to the model have been streamed to the client.
- A part moves on the server and the motion triggers an event on the client. If the part wasn’t streamed to the client before the motion there is no guarantee that it will be streamed by the time the event fires, even though it moves close to the client before the event.
Note that for all of these situations if the part happened to be far away from the client instead of nearby then there has always been similar behavior where the part would exist on the server but not yet be present on the client.
Developers may need to use WaitForChild and other techniques in these situations rather than assuming that events and property updates always occur at the same time as part streaming.
Additional notes about change:
- We treat assemblies with anchored parts slightly differently from assemblies with only unanchored parts. If an assembly consists of only unanchored parts then the entire assembly will be sent as an atomic unit. For assemblies with an anchored root, only parts/attachments/constraints needed to link streamed parts to the root will be sent together.
- Avoid creating moving assemblies with very large numbers of instances unnecessarily. Since we will send all the instances together if any part is near the client focus this can result in network/CPU spikes.
Timeline:
We intend to enable this feature globally on March 14th to give developers time to develop workarounds for the timing changes if needed. We plan to enable it in Studio on March 7th so developers can test the new behavior and implement workarounds if needed. If you think enabling this feature in this timeframe would place an unreasonable burden on you as a developer please let us know which aspect is problematic and what it would take for you to work around the change.