^^^
I’ve resorted to making my own chunk systems because of this haha
4 Likes
I don’t know of any plans to move Streaming properties from Workspace to a separate settings area, Do you have a use-case that would be improved by moving them?
Streaming only operates on instances under Workspace, so it seems reasonable to have Streaming settings be properties of Workspace.
14 Likes
I think its more of a general question, though this seems to just compound it. The workspace instance is currently full of properties that, at least to a lot of people, seem like they’d be better placed somewhere else. They all do have an impact on the function of the workspace, but it just seems cluttered.
No real usecase or anything to move streaming specifically- its always been there, but the other properties that are temporary could be in a settings menu. I’ve had a lot of people get confused when i tell them how to enable these certain things because the idea of them being a property of workspace is unintuitive i guess? It doesn’t matter in the grand scheme of things, just a general complaint i see.
9 Likes
The only thing that I can think of that would benefit for if the properties were moved somewhere else, is the fact that having them as properties incorrectly implies that they are either meant for a scripter to use or that it is probably scriptable (which is not the case - except for the StreamingEnabled property itself, although I wish was) moving them to a place-setting would more accurately reflect that the property cannot be changed via plugins or at runtime, but that’s more of UX nitpick than a full-on reason to change it, especially when you could end up opening up script access to the properties eventually.
4 Likes
Seems like the ‘client’ and ‘physics’ was dropped from this new naming, does the function no longer just stop client-physics, or was it dropped so the name wouldn’t be soo long?
3 Likes
Here are some use cases I wrote up a while back:
4 Likes
What I mean is that there has to be a better place to store settings, e.g., ReplicateInstanceDestroySetting; I don’t think that settings should be stored in the properties of the workspace.
7 Likes
If streaming pause is viewed as one tool, wouldn’t it simply be better to put streaming settings under game settings instead, or even make an instance similar to terrain under workspace that soley changes streaming behavior, it seems like putting all these properties under workspace should not be the case
Workspace does not only target properties related to streaming and physics behavior, it has properties for allowing third party sales, animation weight blend, signalbehavior, etc. Workspace is not for most of these behaviors. If I was looking to change some behaviors in my game, I’d look at game settings, not workspace.
If I wanted to change signal behavior, I would change it under the event instance, not workspace.
If I wanted unions to scale nonuniformally, I would change it under union operation, not workspace.
The best use case of this explaination is, I would like to not have all of my instances affected by one change at a given time, I may not want my events to be deferred for all, and instead have some be immediate. What if I want some of my touched events to use collision groups and some not to, why does one change effect the entire experience as a whole.
short:
Properties that belong to workspace are there, and they have to do with physics, but many properties having nothing to do with workspace are under workspace.
This is my thought.
5 Likes
Doesn’t this defeat the purpose of StreamingEnabled? One of the whole purposes of StreamingEnabled is for content to be loaded/unloaded when it’s impactful to the player to save on memory (e.g. visible parts or parts which might come into contact with things around the player)
An object isn’t important if it’s far away, if you have code or functionality that relies on that object even if its far away, typically it’s not a conflict of StreamingEnabled, because you designed the code in a way where the object is important even though it’s not impactful to the player.
In my experience there’s always good ways around any conflicts you face with streaming, I’ve never had unsolvable issues with it that required me to try and like rewrite it, or replace it. For example, most problems can be solved by just writing things to be more based on events (e.g. ChildAdded, WaitForChild, or FindFirstChild). Or alternatively, using a component architecture or CollectionService.
Side note but plus, when you try and do this yourself you’re undoubtedly not saving performance or memory anymore in most cases, because you’re no longer streaming. StreamingEnabled isn’t for reducing the amount of stuff being displayed, it’s for reducing the amount of stuff that exists in the first place, primarily to conserve memory, but also CPU and GPU performance.
A custom chunk loading kind of thing I could imagine will eat up a hefty amount of CPU with minimal savings on GPU performance except if your game is like very heavy on textures or triangles or something (which implies there’s room to improve in that regard) or if you can take big shortcuts like with voxel games.
They’re both different in their use cases and drawbacks and benefits and streaming tends to be quite light on perf in my experience.
3 Likes
Your existing settings for Workspace.StreamingPauseMode Will be automatically migrated to the equivalent for
4 Likes
I see, thanks for the explanation.
3 Likes
It looks like you’re just trying to save the Roblox developer team from being lazy to add such a simple option if they know what they’re doing, and I’d also rather disable it if it’s literally streaming every object, which will lead to, what do you call it? “not saving performance”; We know that creating a custom render system is much worse and that’s why I’ll try to suggest my suggestion whenever I can.
Moreover: if something similar to this feature is launched then normally of course it will depend on the user how much they use it but for me I would only use it on a few core assets that only have the lowest cost of performance but we shouldn’t stop them from adding this feature just because Some people think this is unhelpful to streamingenabled.
3 Likes
No. This would greatly improve the flexibility of StreamingEnabled.
Currently if I was to make, for example, a high speed train simulator I would have to make low detail surroundings and make StreamingTargetRadius really high, otherwise player on slower (not even the slowest) connections would constantly get physics pauses.
If Roblox adds a way to make StreamingEnabled ignore certain objects, I could make it so that only non-vital things like scenery are affected by streaming, while important objects like train tracks stay loaded in at all times, effectively dropping the need for client physics pauses, resulting in a better user experience.
2 Likes
Tbh, I’m fine with having them in the workspace, I don’t have any issues with that.
1 Like
This wouldn’t reduce the amount of pausing afaik, but I can see where you’re coming from here. I’m not sure, I still am of the opinion that it’d be more detrimental than beneficial. 
1 Like
My point is that I would be able to disable pausing entirely if all essential objects were loaded in at all times.
1 Like
I was asking a genuine question there and I’m making a genuine point.
StreamingEnabled is primarily meant to conserve memory, and when you make it easy to turn off without justification, it very quickly is able to defeat the purpose, and people will misuse it the moment they have the opportunity to.
I just don’t see the benefit, don’t understand the justification, and having seen what things people can do to their games in the name of performance makes me really not want this, because it’d come up in my work a lot like many things do.
If your goal is to improve performance, you need to target exactly what causes lag in your game, trying to cover it with a blanket solution doesn’t ever work out, aside from the fact that StreamingEnabled just isn’t meant for improving performance, it’s meant for improving memory usage and reducing the amount of stuff that’s around.
The main case I can come up with a problem that doesn’t have a necessarily good solution is around physics, because when stuff isn’t streamed in, there’s nothing there to collide with, so objects with client network ownership will fall unless streaming is set to pause.
However, this isn’t solved by being able to remove certain things from being streamed either.
I don’t think that being able to remove certain objects from streaming really solves this still. Sure you can make the tracks always loaded, but, it’s not a whole lot different than it was. In one case you’re waiting for the tracks to stream and in another case you’re waiting for the world around them to stream.
Wouldn’t being able to tell Roblox to prioritize the tracks be better? Or making other content lower-priority or “unimportant” to StreamingPauseMode so that pauses only include certain important objects?
I feel like Player:RequestStreamAroundAsync() would be a better albeit imperfect solution to your track issue, and then you can even leave StreamingPauseMode on.
3 Likes
Tracks are an essential gameplay element as physics will fail without them, while scenery is not, and in case where only scenery is streamed, physics pausing can be disabled. I bet players on slower connections will be fine, even if they sometimes don’t see some parts of the scenery.
It would allow for great reduction of the target streaming radius as well, reducing the network traffic on clients in cases where the map is dense.
1 Like
That’s true, what I was kind of pointing out though is that if there’s only tracks and no game I don’t see the difference, since either way you’re still looking at nothing while the world loads, in both cases you’re waiting.
I think I’d still suggest using RequestStreamAroundAsync ahead of the train or something, it’s sort of an unsolvable problem right now I guess. I still really don’t think that being able to remove certain items from streaming makes much sense, even if they are essential.
If there’s not really a better solution introduced in the future then I don’t really know, I’m just not sure that it’s the right solution even for your case.
3 Likes
Same here since streaming enabled does not stream out, really noticeable in big maps, if it would stream out the size of maps wouldnt even matter but it still does.
I mean they don’t do bad work at all but that Maps render up to 100000 Studs is absolout useless on roblox and just makes it extrem hard to make Big maps playable on many devices.
2 Likes