What's Next for Streaming - We Need Your Feedback!

[knightmb1 (KnightMB)]

@Maximum_ADHD

If it already works like this… then I guess we’ll probably have to look at more aggressive optimizations on our end? Ideally the server slowing down shouldn’t be that big of a deal for the playability of our game. There’s just a lot of compromising balances that have to be made.

I don’t know what design decisions were made in the past, but for your issue it would be easiest to use the LowMemory mode, set the radius to the lowest value 64, then dynamical load the world around the character as they move. This helps low end devices because the small radius means they can swap our memory sooner for performance reasons or for those on systems with a low amount of system memory. For users with high system memory, the low radius helps with things a mile away from being rendered and burning CPU time on the client since you’ll have control on how far away they can see normally.

[CorvusCoraxx]

Thanks for your feedback on the known issue with post-replication subtree addition. We will discuss prioritizing addressing this problem.

On your point about ReplicatedStorage and ReplicatedFirst, can you give more detail on what you would like to see? Currently streaming only operates on instances under Workspace, so instances under containers like ReplicatedStorage are not subject to stream in/out. Are you saying you would like streaming to be applied to other containers in addition to Workspace?

[EmesOfficial (Emes)]

Thanks for your feedback on the known issue with post-replication subtree addition. We will discuss prioritizing addressing this problem.

Thank you so much, this is honestly the main reason I’ve created this post.

On your point about ReplicatedStorage and ReplicatedFirst, can you give more detail on what you would like to see? Currently streaming only operates on instances under Workspace, so instances under containers like ReplicatedStorage are not subject to stream in/out. Are you saying you would like streaming to be applied to other containers in addition to Workspace?

Yes. I believe all rules should be applied to other containers as well, but with a difference that instances in these containers should not be streamed in even within the StreamingTargetRadius range. Basically a non-atomic model under ReplicatedStorage shouldn’t replicate parts to a client. An atomic model should not exist to a client. Persistent should have everything streamed in.

I want to make this clear. In my first post I said things make the development exhausting. This is not one of them. It doesn’t affect the development, but would make the streaming feature more effective.

My next point was related, because to make it easier for devs sometimes you store parts without a model, rather in a folder under ReplicatedStorage (ex. as a position data). If streaming rules applied in replicated storages you couldn’t even make these parts persistent in that case, so in my opinion they should act like persistent instances

[apenzijncoolenleuk1 (Apenz1)]

Please give us more analytics. As far as I know, there’s no way for us to know how much memory, and network bandwidth streaming uses. This is crucial information to debug crashes.

[drager980]

Trying to design a massive game for PC and mobile but currently I’m either lacking knowledge or there is no way to set a streaming radius for smaller / weaker devices and allow for higher end devices to store more / unthrottle themselves?