The entire workspace is always available to the server, right? (So that I don’t have to account for things being streamed out/in doing server-sided coding) Because the streaming only happens on clients?
Say I connect some functions to events on a part. If the part gets streamed out, when it gets streamed back in, will it still have those event connections? This is so that when I code, I will know I only have to account for parts that aren’t available to the client initially, and not parts that already had events connected to them and then were streamed out.
If a part gets streamed out, will references to that part stored somewhere still be usable?
Example:
local part = workspace.Part
wait(10)
-- Let's say the part gets streamed out during this waiting
print(part.Name) -- Would this throw an error saying the part is nil?
part.Position = Vector3.new(10, 10, 10) -- If the reference is usable, when the
-- part gets streamed back in, would its position have changed because the code
-- ran successfully even though the part wasn't in the workspace?
Note: I know I could test out some of these to find the answer but I’m not on my PC right now
So here is the deal with workspace.StreamingEnabled: it is used for loading parts of the world with minimal lag and network issues. This means that players will not lag (as much), players won’t fall out of the world, etc. It also helps with:
Faster Load Times — Players can start playing as soon as part of the world is loaded while more of the world loads in the background.
Wider Device Support — Games can be played on devices with less memory since content is dynamically streamed in and out.
Terrain Level-of-Detail — Distant terrain landmarks will be visible through lower-detail meshes even before they are fully streamed in.
If a player is lagging or has poor connection, the player paused gui will appear. This will suspend their client from making physics interactions within the world. With that background in mind, here are answers to your questions:
Yes, the workspace will load as soon as the server is created. From what I have seen, streaming only caters to laggy clients. Both are true.
If the part has been streamed out, no connections will break. This is speaking from personal experience.
No do not use this, if will throw an error. Instead use this:
local part = workspace.Part
wait(10)
-- Let's say the part gets streamed out during this waiting
print(part.Name) -- yes, because part is not loaded
part.Position = Vector3.new(10, 10, 10)
player:RequestStreamAroundAsync(part.Position) --use this to stream around part
Keep in mind, these should all be Localscripts as a serverscript will always stream in.
For games where StreamingEnabled is set to true , requests that the server stream to the player regions (parts and terrain) around the specified X , Y , Z location in the game world. It is useful if the game knows that the player’s CFrame will be set to the specified location in the near future. Without providing the location with this call, the player may not have streamed in content for the destination, resulting in a streaming pause or other undesirable behavior. The effect of this call will be temporary and there are no guarantees of what will be streamed in around the specified location. Client memory limits and network conditions may impact what will be available on the client.
visual effects that are coming from the server doesnt stream in unless i use RequestStreamAroundAsync which is kinda bad every time i have to do this for a visual effect