Sometimes games have parts that need to be streamed no matter what. I’ve had weird luck with streaming where it will not load stuff near the players or it won’t load big parts. I would love a method that allows me to denote a path or paths in the workspace that will always load for the player so I don’t need to worry about important things not loading correctly. I could force the ground to load or the map wall. I could force their tycoon to load but nobody else’s. I hope this suggestion is considered.
Are you using FE? If so, just wondering, what happens if you put a model of these parts in ReplicatedStorage and then have each client drop it in workspace locally?
2 Likes
That might work. I’m not sure exactly how streaming works.
1 Like
One of the uses of streaming is to reduce RAM on the clients computers. Getting things from ReplicatedStorage is fine for a level of detail type script but wont reduce the use of RAM on the clients computer cause its replicated. Works fine for reducing FPS though, if thats what your trying to do. Streaming just downloads parts as the client needs it (AKA when its in use or your near the part) although this can lead to a ton of bad things if your calling things locally and they haven’t been streamed in yet. Id just make your own type of system that copies in blocks of the map from replicated storage when you get near them and remove them when you get far enough away.
-Wid
2 Likes
My suggestion was based on the fact that StreamingEnabled is turned on as well, and he only wants certain blocks, such as the ground or certain barriers (which I assumed would be like < 100 parts total) displayed all the time, so for that low amount I think you can afford to do that. Everything else would be streamed like usual.
Only the thing where people can see their own tycoon may be more difficult since he wants the tycoon to be visible for the player themselves always, but should be streamed for other players, so that requires a bit more scripting and doing more stuff locally.
I would totally use this for scenic areas from a distance. Maybe I don’t want to render the house next to the waterfall when you’re on top of a hill but I want to render the waterfall itself because you can’t really see the house that much (or maybe replace the house with a lesser detailed one).
2 Likes
I was working with streaming and found out that my game will basically be 100% broken if I use it because I have no control over what replicates to the client.
I can’t just clone models out of ReplicatedStorage because I need some items to replicate across the server and it’s not exactly easy (or quick) to do that manually. Also, I need other players’ characters to replicate as well and there’s no way I’m manually replicating them too.
If streaming is going to be the new default soon, we need a way to force replication of certain parts.
3 Likes
It’s unfortunate that this is still a problem 4 years later…
There are many solutions Roblox could give us to fix this including: Tagging parts to force replicate, a service with methods to force replication, or a new object that can be selectively replicated. It would be good to know that they are at least working on a solution. For now, I will have to stick to keeping streaming turned off and manually controlling replication.
3 Likes
Some sort of additional control on what’s streamed in/out is pretty much essential in my eyes.
Even local parts (or reparented parts from an always-replicated storage container) are streamed out when the chunk they’re located in is streamed out. I very frequently use local parts to e.g. highlight some area, show a preview of what the player is about to construct, locally animated things (loaded in when some anchor part streams in), etc. — these can all stream out if the parts are parented to the workspace.
I just want to force these small amounts of local parts to never steam out, even if that means that another chunk of server-sided parts can’t stream in. It’s a huge pain to design localscripts in a way that supports any local part randomly being streamed out.
The only way to “ensure” some local part is always visible is by detecting the local parts being streamed out (and thus never be streamed in again), then instantly re-creating the part…
4 Likes
I’m having the same issue. I need a part to be visible at all times, no matter where the player is on the map. Even if I put something in ReplicatedStorage and parent it to workspace, it still streams out. I’m not sure if there are any solutions to this problem yet.
Edit: It seems like the way Roblox changed the way local parts are streamed in/out last year may have actually fixed this issue.It just doesn’t seem to work in play solo mode. If it is fixed, I apologise for bumping this thread. More info can be found here: Streaming Prefetch API and Improvements to Part Handling
1 Like
Locally created parts shouldn’t be streamed out, unless they have an ancestor that is a remote part.
If you reparent something out of ReplicatedStorage into workspace it will be considered a remote part, subject to stream out. If you clone something from ReplicatedStorage into workspace it will be considered a local part.
7 Likes
Thank you, I fully understand how it works now. The only slight issue I had was in Roblox studio - the behavior of local part streaming in the “play” solo mode seems to be different from the behavior in the “start” server mode and in-game, which is what lead me to believe that this was not fixed. However, this inconsistency is unrelated to the topic of the post, and probably doesn’t even count as a bug, so I once again apologize for commenting here.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.