Tbh, I’m fine with having them in the workspace, I don’t have any issues with that.
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.
My point is that I would be able to disable pausing entirely if all essential objects were loaded in at all times.
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.
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.
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.
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.
This is just a band-aid solution for anyone who actually needs the ability to force certain objects in streaming that decreases performance as it streams the entire MinimumRadiusPause area, not a specific instance (that would be much more efficient), currently the only option for streaming in a singular object, is to create a copy of the object on the client and replicate physics as needed.
There is no change in the functionality. When it triggers it will still pause client-side physics. The name was changed mostly to differentiate it from another mode that we will be adding.
In the short term (next couple of months) we’re also adding a new mode that still pauses, but will pause less frequently in most situations. The tradeoff is that it offers different guarantees from
MinimumRadiusPause
, more on that to come later.
Why would they do that? Workspace is the service used for rendering so it’s definitely ok to use it for these properties
A more appropriate location for these sort of behaviour settings would be a an actual settings menu or another instance. I don’t agree that the Workspace should have properties which are actually settings like ReplicateInstanceDestroySetting
. Properties suggest scriptability, something that behaviour settings are not.
This topic is about Workspace.StreamingPauseMode and Streaming in general, which is used for rendering, what does ReplicateInstanceDestroySetting have to do with this? Plus instance destroying kind of has to do with workspace as well. I like it as it is
I do agree replicate properties should be under network server or some service like that though
No, settings should not be stored as user-facing properties in the first place. Settings are not scriptable properties - it’s better UX anyway to manage them in some sort of settings panel.
Looking forward to better streaming solutions, but until we get per-parent streaming options, the feature as a whole will not be useful to me.
Those settings are not scriptable though, what are you saying???
Yes, that’s right. They aren’t scriptable, so they shouldn’t be user-facing properties.
Ok. Someone help me out here.
What exactly is streaming mode? It’s turned off in my game. But, from what I can ascertain, it allows partial downloading of the map. Specifically objects that are in the immediate vicinity of the players first. When that’s done, it downloads the rest of the map in the background which allows the game to load faster.
Am I correct in this assumption?
Parent the things you don’t want to stream to the camera.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.