Streaming + Network Ownership + Low Memory = Infinite Physics Sleep

Due to the new memory simulation feature in studio I have discovered an issue in my own game. Upon further investigation (the issue was extremely strange and I couldn’t figure out what was causing it), I discovered that it was an unusual overlap of streaming and network ownership.

Essentially, when a part is owner by a player, and that part is streamed out on that client, the part enters into an endless sleeping state. A repro file is attached here:
StreamingSleepRepro.rbxl (18.4 KB)

I tested using a device with 250MB simulated memory (although this does also occur on devices with higher amount of memory, and seems to sometimes happen during loading of new parts on devices that have more than enough memory). The issue seems to resolve itself and work better on devices with higher memory, and parts will reawaken when the player comes near, but on low memory devices the part will enter an infinite sleep state.

If a part enters this infinite sleep state, it is impossible to interact with it using physics. Body movers have no effect, and neither does pushing it with my character. I have also tried toggling some properties like CanCollide and Anchored to no effect. It does seem possible to re-awaken the part by creating local parts inside of them or inside my character (even reawakening parts that are far away) - but this is a quick fix I am using and to be honest I have no idea why it works.

The issue does not occur with parts set to automatic ownership.
As far as I can tell, the issue occurs online and in studio (although online testing is more difficult due to the requirement of having an actual device).

Parts can also enter this strange sleep state if they are a little bit away from the character, and not even actually being streamed out. I am not sure why this happens, but it also seems to only happen on low memory devices.


High memory device standing nearby - everything working correctly:

High memory device standing far away - Parts go to “sleep” but only the client owned part actually freezes:

Low memory device - Client owned part freezes and cannot be woken up, while other parts behave (mostly) normally:

Notice that in this video the issue appears immediately, although in some of my tests the red ball behaves normally for a few seconds before freezing.
Notice also that the client does not seem to think that the two other balls are awake. No apparent issues because of this, but it sure is strange.

Since I have a quick fix for this issue I haven’t done thorough research into it, and there may be more edge cases that cause this behaviour. If anything else is needed from me (repro from my in-dev game, etc.) I can offer them if there is staff interest in fixing this.

I hope this issue can be worked out soon as Roblox transitions towards streaming being the standard. This prevents local parts (pets, cars, etc) from behaving predictably and consistently, on the very devices that have the most to gain from streaming.

Low memory devices put parts permanently to sleep if you give them network ownership of the parts. This only seems to happen with StreamingEnabled turned on. The parts can be woken up but instantiating new parts nearby them, but physics interactions cannot re-awaken them.


Thanks for the clear instructions and repro place. We will investigate.


A workaround you should be able to use to avoid this issue for now is to use a minimum radius of 192 or larger.

I am working on a better long term solution. There appears to be a bug in our simulation radius calculations.


Thanks for the workaround and quick response. I can confirm that this has fixed the bug in my active project as well as the repro place I sent.


@CorvusCoraxx bumping thread because I’m running into an issue with this now too. I have some autonomous drones that end up freezing once they get too far away from the character. Setting the minimum streaming radius above 192 didn’t seem to solve the problem.

It looks like the freeze is appearing right at the streaming cutoff point or something: (Edit: This is the cutoff point for Player.SimulationRadius)


If the client doesn’t have those areas streamed to it then it can’t do correct physics simulation in those areas. I wouldn’t recommend setting the owner to the client when it is far away from the player. Could you do something like change the ownership to the server when it gets near to the simulation radius cut-off?

1 Like

Unfortunately SimulationRadius has a permission level above what scripts can access, so I can’t do it cleanly. The only option I have here is by setting network ownership to auto and then constantly polling with GetNetworkOwner() to watch for changes (there’s no event for it).

What are you using for your streaming minimum radius? Could you perhaps set your minimum radius to the distance you expect the drones to travel around the player, and set the owner back to the server if the drone is beyond the minimum radius distances from the player?

I was just testing this again for a new project, and (at least with the repro file I linked above) it looks like the issue is resolved. You should be able to use small streaming radii without encountering this particular issue.

Nevermind, it still seems to be happening in game for some reason, although it seems fixed in the repro file. Jumped the gun a bit on that one :sweat_smile:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.