This especially, is awesome. I’d really want to make this a setting in my game or have it as a script-controlled automatic setting for players with different hardware and network conditions.
By the way wouldn’t it help the server performance more than hurting it? If I have 20 players with 256 min. streaming radius vs 10 with 256 but 10 with 96 for example.
While I’m here I’d like to give some feedback:
There’s a bug which results in terrain loading spiked (with deformed triangles) if streaming radius is less than 96. It happens with 96 and 64 and doesn’t happen with 128 min. streaming radius, I think this is a known issue, is a fix for this on the way?
I use a system where elevators teleport to upper floor or another terrain piece. Players can use it together so I can’t yield the elevator for player loading, if I don’t though, some players just fall off of the map while loading. I have to use some sort of invisible local part tricks to fix this, maybe the collision data should be provided earlier than terrain textures or I’m sure Roblox has a better solution, just wanted to give feedback on this.
Your code relies on polling and weird magic numbers, here’s a version I’ve used for a long time for my own game:
local function WaitForDescendant(Parent: Instance, Child: string, TimeOut: number?)
local AlreadyFound = Parent:FindFirstChild(Child, true)
if AlreadyFound then
return AlreadyFound
end
local Connection
local TimeOutThread
local Thread = coroutine.running()
Connection = Parent.DescendantAdded:Connect(function(Descendant)
if Descendant.Name == Child then
Connection:Disconnect()
if TimeOutThread and coroutine.status(TimeOutThread) == "suspended" then
task.cancel(TimeOutThread)
end
task.spawn(Thread, Descendant)
end
end)
if TimeOut then
TimeOutThread = task.delay(TimeOut, function()
if Connection.Connected then
Connection:Disconnect()
task.spawn(Thread)
end
end)
end
return coroutine.yield(Thread)
end
I wonder if any of this solves the consistent replication problems I have been having.
I needed to play an animation when a part spawned, what I was doing before was firing a remotevent with the part as the argument, then animating it. With streaming enabled, even with the parts being marked to always be persistent, the parts were “slow” replicating - They were taking the Streaming process despite being persistent, and therefore came after the remote event fired, not before.
I got around that problem by giving them a unique ID tag so that if this happens, I can use the collection service to figure out what the part is still (probably a weird way to do it, but I had no other options)
Unfortunately this lead to a further consistent bug that I can’t even tell if is in my code or roblox’s - Everything fires correctly, but the things never animated. I think at the time of checking, the properties were seemingly changed correctly but were just… wrong. Like because of how I did it, it just wasn’t applying my changes or something very unusual. I’d print, it’d say it’s made the brick do what I want, but then would still just… not have an effect. Literally could not track this one down because it’s embedded into a lot of unusual code, so it’s hard to tell how far the rabbit hole goes here!
So, here is a major streaming issue, and this is the sole reason why I do not use streaming on any of my places.
Let’s say I have a place focused on trains, which happens to be all of mine quite frankly. If I have a train which is, say, 20 cars long, everything is fine. However, if I have a train that is 40-50 cars long, the rear end of the train un-streams because it is farther away and the whole thing freezes and breaks. This is because there is no way to adjust the way object physics streams. The railcars on the train are connected via constraints, usually rods or ropes.
For this reason, my places will never use streaming because trains of that length are commonplace for us. As a replacement, I use a client-sided chunk loader for scenery objects, which isn’t as efficient as streaming would be but using streaming is physically impossible in our places.
I’m not exactly sure what the problem is - Streaming enabled somewhat recently has given the option to make things persistent. You can set the train cars, at least the base/primary parts of them and such, to be permanently streamed in. You can also set the entire train to Atomic, which would mean the train only is either loaded in, or loaded out, with no inbetween.
If the train is being physically controlled by the server, I don’t see how this would cause issue. Can you describe the problem more in-depth, as well as telling me some of the steps you’ve already tried to fix it with? There might be some solutions yet to the issue, rather than it being a problem with streaming enabled.
I agree with this. Render performance out of the box should get better.
Right now, achieving a high framerate on these large worlds is 100% possible, but needs (arguably considerable) manual intervention, by running systems such as custom distance culling (that also takes into account the importance of the object - so, stuff like pebbles should only be rendered while close), and LODs. I’d say Roblox’s largest rendering performance draw right now is the fact there is no occlusion culling.
Edit: I mean these systems can and have been made in Luau, which is able to run them with good performance, if optimized well.
While i’d like to give them the benefit of the doubt, I’d reckon they might be giving an individual player network ownership in this situation. That sounds like the quickest way to make a train stop functioning - second the player with physics ownership steps away from part of the train, the entire train stops functioning.
This however forces Roblox to go through the entire workspace hierarchy (until it finds the desired instance)every heartbeat which is wildly wasteful and inefficient, this may not cause problems in a very small game but in games with a lot of instances it will have to go through this can definitely impact performance.
I’m hopeful for the addition of the streaming exclusion feature. Being able to exclude certain models from being streamed to specific players is the last missing feature for StreamingEnabled in my opinion.
A important need for some would be to toggle how select objects are streamed, or a similar method, for railway based games, if you attempt to run a long train, streaming will “shut down” on the cars farthest from the player, making for a frustrating experience for the player, who will derail or get stuck.
You seem to be saying the exact same thing that @ Hachiroku did, which as far as I can tell doesn’t appear to be valid critique? If you could read through the replies just above, I’d love to know what the actual issue you’re having is, as Streaming Enabled seems to be 100% set up to handle what you and Hachiroku are saying here. Just sounds like you aren’t using it right.
The TL;DR is, we literally do have the ability to toggle how select objects are streamed. You just probably aren’t using them.
I’d really like to see streaming based on occlusion in addition to distance. It’s a waste of resources to replicate instances that the player can’t see.
That Exclusion Mode sounds very nifty. It’ll let me safely host my scripts in Workspace without hackers being able to copy instances in workspace, since I can exclude the script objects from being streamed – which, in turn, prevents workspace copy scripts from reading them.
Doing so would actually be a very big step forward for Roblox, as it would allow people to place scripts in Workspace in a secure manner. In turn, this change allows people to delete entire chains of WaitForChild() or the various WaitForDescendent() implementations people have posted here. No more game.Workspace:FindFirstChild("Game Objects"):FindFirstChild("Tycoon Blocks"):FindFirstChild("Upgrader 1")... chains!
TL;DR: adding Exclusion Mode would allow people to return to an object-oriented programming style that Roblox was originally visioning in the first place, as well as giving me the ability to hide Workspace objects from clients, such as anti-cheat range checkers to prevent flying and speedhacks.
I don’t think you’re quite aware of how roblox scripts work. Roblox never has and never will send the bytecode of server scripts to clients so exploiters never could copy your scripts but they very much do and need to send the bytecode of local scripts which exclusion mode won’t really solve since for those local scripts to run the bytecode has to be sent to the client.
The bytecode of server scripts in Workspace can be replicated through a few exploits (though, admittedly, most of which rely on some things to be set up in a certain way – if there are any that can do it without a specific framework in place, I’m not aware of them.)
But my issue is moreso that I want to be able to hide objects from the client - not bytecode. If, say, an exploiter finds a script and a remotevent in the workspace, it wouldn’t be hard to guess that spamming or exploiting the remoteevent affects the script in question - ergo people ticker with stuff that shouldn’t be tinkered with. Yes, I could put it in ServerStorage, but now I have to deal with a dozen WaitForChild calls for objects inside a non-atomic hierarchy.
