Bug Report Details: Cloned parts are still streamed to the Player when they (the parts) are beyond the StreamingTargetRadius when using LowMemory mode instead of Opportunistic.
Where: Roblox Server
When: Always
Environment: Windows 10, 16GB of RAM or Windows 7 Pro, 16GB of RAM
How to Reproduce: An example map has been included to show this. When you start the map, it just starts cloning parts in random locations and colors. If you run away from the cloud of parts, like really far away, well beyond the 128 stud limit, you can still see them cloning and the client script counts the distance and parts shown from the Client perspective continues to rise even though the Player is very far away from it all at this point. This does not happen if you switch it to Opportunistic mode and run the same map, run away from the cloning cloud, etc.
[edit]: I updated the Demo File with a script on the workspace named “CreateLikeCrazy”, if you enable this script, it will create parts instead of cloning them and the same behavior happens. Demo File Attached: bug world demo.rbxl (53.3 KB)
This behavior is by design. Once the server has streamed a region to a client we try and keep that region complete so that it accurately reflects all the instances that exist in that region. So if a region has been sent to a client and then subsequently parts are added to that region we will send the newly added parts, even if the region is far away from the player (beyond target). This helps us maintain consistency and allows the server to know what regions the client has (meaning everything in the region).
If you are concerned about the cost of replicating these far away instances then the only suggestion we can make currently is to use opportunistic stream out as you identified.
I will run another test with the smallest possible streaming radius to confirm, but it looks like those parts are extending way beyond the 128 stud radius of the region the player started in. So in theory, if I let this test run long enough, it should form a nice sphere of visible parts in the middle and not extend way out to the edge correct?
This experiment, I set the target radius to 64 and then had the client outline the path of the player with a 64 radius sphere as I was walking away from the center. I just stood around for a few minutes to let the replication build up randomly around the center. As you can see, those parts are being streamed in well outside the region of the path I walked away from. Is the base plate itself causing all those parts to stream in, even though they don’t touch it, not part of a model with it, etc?
A radius of 64 will actually give you a center region of size 64x64x64 and then have the neighboring regions in each direction that are also 64 cubed.
If you turn on the “Render Streamed Regions” visualization in Studio you will see this:
The green boxes are streamed regions at your current elevation. The yellow box is due to a part overlapping that region, but the region itself is not actually streamed.
Excellent, this should help me test some other configurations then. I appreciate all the technical help. I didn’t know the streaming radius worked in cubes.
Ok, so to help me understand. The red radius path traced out by my player movement is within the 64 stud radius, the cube being shown is the additional 64 stud distance. I can see from the 2d map where my player is the red dot and cube around it are the streamed areas. So looking at the two screen-shots where I rotate the view a little, I can see parts on the left and right side that are way out there from my starting path. So those few parts are still within the streaming radius of my original path? It doesn’t look like it visually, but I think I need to better measure part distances then just to confirm because maybe it’s an optical illusion, but it really does look like a lot of parts are still visible well outside a 64 stud grid where the player was.
This is better experiment setup:
How this works, when the map begins, the player sits on the spawn point for a few seconds, then teleported to another spawn point far enough way to create a “hole” in the streaming regions and then just let the player sit there for a few minutes. The first screen-shot has a red sphere in the distance, that is where the player started.
The second screen-shot shows what happens after a few minutes, the red sphere is where the player is centered on the base plate. I realize that some parts may touch two regions as you mentioned and thus light up the yellow part of the grid, but it still seems parts are streaming in way outside of the target streaming radius. This does show that the hole works as you don’t see a pile of parts between the starting point and the current position of the player, so I agree that it is working as you said, but it seems to have so much spill over that it creates the illusion that everything is streaming in regardless of distance when you are looking at this from the perspective of the player.
So this may have some benefits as it means developers can use a much smaller streaming radius target than what seems intuitive, so that would speed up the game for clients. But… it seems to have so much spill over that this is creating a fighting effect on clients when a memory limit is reached but a streaming target is not met. From what I’ve seen on mobile clients for example, parts of the map are streamed in, then streamed out because of low memory, then streamed back in again for streaming target, over and over. It usually results in the client crashing on mobile if the memory limit is exceeded faster than the client can stream out to reclaim memory. This is harder to do on PC because everybody probably has gigabytes more RAM than most mobile devices have and probably never see this unless you push it to the extreme like I’m doing in this example map.
it seems to have so much spill over that this is creating a fighting effect on clients when a memory limit is reached but a streaming target is not met. From what I’ve seen on mobile clients for example, parts of the map are streamed in, then streamed out because of low memory, then streamed back in again for streaming target, over and over. It usually results in the client crashing on mobile if the memory limit is exceeded faster than the client can stream out to reclaim memory. This is harder to do on PC because everybody probably has gigabytes more RAM than most mobile devices have and probably never see this unless you push it to the extreme like I’m doing in this example map.
