The wording for Persistent on the wiki is concerning.
Persistent models are sent as a complete atomic unit soon after the player joins and before the Workspace.PersistentLoaded event fires.
…Why are PERSISTENT models going through streaming enabled to begin with? This is inherently slow, and the wording of it gives me fear my assumption in my prior reply might be correct.
Things that are persistent should not be IN the streaming system to begin with. They should be loaded in the old fashioned way, ensuring minimum delay and making sure code involving these parts will 100% work like their non-streaming-enabled counterparts. The added delay of streaming enabled is not welcomed here, and I’m not sure why it can’t adaptably use default replication instead.
Edit: To be clear, I am aware that my use case here is a bit specific. But the want for a part spawned directly near the player to be put in with default replication delay rather than added streaming delay seems perfectly reasonable to me.
This would be something developers have to opt into for existing places, and would be enabled by default for new places. We will be careful to not break existing experiences.
Can you please try it first and give us feedback based on the results of you trying it?
Yes, there is a different signal that fires so if you have any scripts that rely on Persistent objects being there you can wait for that signal to fire before allowing those scripts to run. I think if you give it a shot you’ll notice that Persistent models show up very quickly.
After you try it, please give us feedback and provide use-cases that this solution does not resolve.
Hello, I wanted to follow up on something brought up by @MrChickenRocket in an above post:
We have a few cases where we’d love to utilize a behavior which allowed us to stop an asset from streaming to a player entirely like this / selectively decide if something can even stream to a player or not.
Is this a potential component of streaming the team sees coming? It would be great to hear why / why not as well; the insights are always greatly appreciated!
Is it just me, or does everyone’s proximity prompts break when atomic is enabled for a model? Had to switch my models with “press E to interact” back to default for the prompts to work.
Setting a StarterCharacter under StarterPlayer to use StreamingMode.Atomic will result in it disappearing from StarterPlayer only for the client, the StarterCharacter still works correctly but will never be replicated to the client.
Edit: I checked and this is also true for all modes other than Default, I assume this is due to to them using Atomic underneath the hood
Edit 2: Upon further testing it seems that putting a model with StreamingMode.Atomic in anywhere other than workspace that is accessible to clients will cause it to to never replicate to clients
From testing, it looks like scripts with a RunContext set to Client under a Model with StreamingMode set to Atomic will run again every time the Model is streamed back in, as if it’s treating every script as a “new” instance of itself.
Interestingly, ModuleScripts seem to act normally in that require()ing them will always return the same reference when the Model streams back in instead of being a new instance of themselves, so I think you can store client-side states/variables in the ModuleScript and “reinitialize/reload” everything from the RunContext Client script when the Model streams in again.
You can test it here by running towards/away from the spawn until the model streams in/out. The RunContext Client script will constantly print() the same line while the ModuleScript will increment by 1 whenever the model streams back in. atomic runcontext.rbxl (38.4 KB)
As an aside, the code example for Player:RequestStreamAroundAsync() is wrong – it’s using dot notation instead of the proper colon notation for a method.
I’m getting this too, which is tragic - definitely a game-shattering bug in of itself.
Does so with atomic as well - perhaps every non-default option?
I suppose the solution is to make sure not to use ReplicatedStorage for storing things used by the server. (Sometimes useful if both client and server need an object)
Sure, but it’s taking me a surprisingly long time to locate the code responsible for the issues in this case. Lots of weird behaviors from various scripts across my game.
Weirdly, it seems like if try to read a property of a part I got from a GetInstanceAddedSignal, it doesn’t return the right thing if the part’s property was changed while it was being streamed in?
At least that’s how I’m interpreting it currently.
A part that turns opaque during it’s stream-in has print(Part.Transparency) returning 1, even if I add a significant wait - I can see the part is opaque, even though a wait(1) print(Part.Transparency) is returning 1. This only seems to be happening in StreamingEnabled mode (And was happening prior to this update too, but I couldn’t figure out what was actually happening before)
I’m still trying to investigate to see if something in my code could be causing this, and where that something might be. The bug appears to only happen when I’m putting more strain on streaming, seemingly working fine in some instances.
I’d put it into a bug report but I’m still unable to figure out repro steps outside of my own code, or what is even actually happening…
Setting the ModelStreamingMode in StarterCharacter inside StarterPlayer to anything that is not Default and Nonatomic will for some reason remove all of the GUIs in StarterGui in-game. I’m not sure if this is intentional but it’s pretty annoying. The work-around I’ve found for this is setting the character to Default and setting the streaming mode to a desired mode after like a second after the player’s character load through code.
I don’t know if a similar idea has already been voiced, but I’ll share it anyway:
The ability to set an individual loading distance for an object.
For example, one tree has a distance of 256, while another has 512.
Thanks for this report. We will investigate and fix as quickly as possible. Until there is a fix available I would recommend not using streaming modes for instances not under workspace.
Beat me to it. <insert block of text expressing approval of this idea here>
It annoys me that Streaming -by design- developers have to deal with if they so happen to choose to enable it.
The issues at play:
“enable it”, not “use it”
work around rather than with
dev isn’t in control, streaming controls the dev “… local scripts should be written to be tolerant of parts being streamed in and out.”
if you decide to toggle it at/after the midway point of a project’s development because you changed your mind, glhf converting that project’s codebase (though, that’s to be expected and isn’t necessarily streaming’s fault; what is streaming’s fault is if you decided at the beginning of a project, “lol, why did this ever leave beta with basically no goddam api to interface with it, I’ll pass on that…”- sparing yourself the burden)
Streaming is inexcusably “it’s my way or no way”- and yes, even after this update. Roblox designs streaming like it’s a “one size fits all”, assuming your game doesn’t get more complex than the Closed-course Baseplate™️ they test it in. Anybody who’s employed a workaround to streaming’s behavior implicitly agrees.
The solution:
Let us control replication on a per instance basis. I know what should/shouldn’t be replicated to players to suit my game’s needs, I don’t need a blackbox named “Streaming Enabled” to decide what’s best.
The rest was written here.
Everyone, not just fellas at roblox must understand that a developer’s intended replication behavior for instances in their game is contextual to what they desire and thus the context they desire often goes far beyond distance; devs employ hacky methods because they can’t achieve their creative image when they stay in the super small gap between the velvet ropes. Every reply to every Streaming Update almost always reeks of stockholm for this very reason. People reply with ideas they would like to have implemented to streaming… the idea may be good, might be bad, doesn’t matter in the end, because this is an XY problem.
I love the but i would love them more if there was a GetPersistentPlayers(); the name describes the function well but just in case just like model:GetChildren() it returns a table of players that have been subscribed to this function or player names
