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?
That might work. I’m not sure exactly how streaming works.
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.
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).
I would like this solution: Manually Replicated Folder
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.
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.
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…