Next week we will rename Workspace.StreamingPauseMode to Workspace.StreamingIntegrityMode, and we will also rename StreamingPauseMode.ClientPhysicsPause to StreamingIntegrityMode.MinimumRadiusPause to more accurately describe its function.
Context
We view Streaming Pause as one tool to handle integrity issues in a Streaming-enabled experience. In the future, we’d like to introduce a mode that does not require pausing, hence the rename.
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.
Next Steps
Your existing settings for Workspace.StreamingPauseMode will automatically migrate to the equivalent for Workspace.StreamingIntegrityMode so you don’t need to do anything once this change is live. We will update our documentation to reflect the changes. Please let us know if you have questions!
I always love seeing an update top right it brings a big smile to my face seeing studio get improved everyday even if it’s the smallest thing. KEEP UP THE GOOD WORK!!
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.
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.
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.
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?
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.
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.
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.
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.
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.