How useful is it to have Streaming Enabled?

Hello.

I’m noticing a little bit of lag sometimes on a game I am working on. The game has around 24k parts ATM and I suspect that’s the reason the game is lagging. So how useful is Streaming Enabled with this sort of situation? And do you guys recommend I use it?

Here is a picture of my map so you guys can have more context, and I plan on adding one more map at the end.

Also, in my experimenting, chunks don’t seem to unload when players leave the area, is this just me or is that part of Streaming Enabled?

Edit: I also did check, and any error that occurs is easily fixable.

17 Likes

The positive sides are that the games with StreamingEnabled on will allow larger maps (and more parts!), faster join times and allowing less powerful hardware to run.

The caveat behind this is that everything on client now requires :WaitForChild() to access parts of the game.

You can find more information here: https://developer.roblox.com/api-reference/property/Workspace/StreamingEnabled

8 Likes

I don’t recommend it, I’d advise a custom solution instead. You just don’t get any control, which severely hurts how useful it can be. Additionally, it runs the risk of players falling out of the map because they are in unloaded areas, so I definitely do not recommend thi with typical client-authoritative characters.

12 Likes

Streaming Enabled provides an easy (but not completely great) solution for rendering large maps

Here is my approach to rendering large maps:

Condition: If you have a large map

  • Separate the map into chunks

  • Within lighting, edit the fog to be seen 1000 studs away from the player

  • If the player is within 1200 studs of an unloaded chunk for at least 5 seconds, load the chunk

  • If the player’s magnitude is greater than 1200 studs for a particular chunk for 5 seconds, then unload the chunk

It’s important to make sure that there is at least 5 seconds of certainty so that chunks cannot unload and load repeatedly when the player moves back and forth between the 1200 stud limit.

note: having fog visible from 1000 studs away from the player is important because it prevents players from seeing unloaded chunk areas, and chunks being loaded.

another note: the reason why I say that chunks should unload or load at the 1200 stud magnitude is so that chunks have like ~12 seconds to load before a player who was walking (default 16 walkspeed) directly at the unloaded chunk sees the actual chunk beyond the fog. Depending on the size and shape of your chunks, you might have to tweak some of these numbers because everyone’s chunk size is probably different.

Recent Edit**

New Edit 4/2/19

There are two new workspace attributes: StreamingMinRadius and StreamingTargetRadius which gives you more control of the map rendering (for streaming enabled) - which makes streaming enabled a lot better!

64 Likes

May I ask why do you think that it’s not completely great? Right now it’s what I have implemented and it seems to work fine.

I’ve visited many games that use streaming enabled, and I dislike how I can see parts of the map start to render when I zoom out.

Edit:

Originally when I made the post above, there wasn’t StreamingMinRadius and StreamingTargetRadius for streaming enabled, so I didn’t really favor streaming enabled at the time. Without a customizable streaming target radius, it wasn’t a great solution. Now that those features are available, I recommend using streaming enabled for most games!

1 Like

Well I’m not sure how much falling out of the map will be an issue since there is minimal teleporting involved in the game.

I have a limit on how far you can zoom out, so that’s not an issue that I would really need to worry about I think.

Seems like everyone mentioned the only caveat to Streaming Enabled is having to use :WaitForChild()

This is not the only caveat. Which even the Documentation seems to miss. It also increases the network usage. Or simply put. Uses more data. Personally I feel like there should be some kind of disclaimer or warning when joining games on a mobile device to tell the user they are in for a couple hundred dollars in a few hours.

Edit: This gets worst when paired with Smooth Terrain. And that’s mainly the case I’m targeting.

6 Likes

My map has 44,000 parts, a ton of complex unions and runs with 50 players.
It doesn’t lag, are you sure your scripts aren’t causing any memory leaks?

How can I tell if scripts are causing memory leaks? Also my game doesn’t lag on my PC, it’s on Xbox that I mostly notice lag.

1 Like

Oh right, I normally centre my game for PC.

If you press F9 and go to Memory > Server if it vapidly goes up constantly then you’ve probably got something causing a leak.

An example

Button.MouseButton1Down:Connect(function()
-- random code
Remote.OnClientEvent:Connect(function()
end)
end)

Above is an example, couldn’t think of a good one on the top of my head but you should disconnect or remove instances you aren’t going to need in the future.

Someone else probably knows a ton more examples of what can cause memory leaks and lag ingame

2 Likes

If you’re talking about people using mobile data, then they shouldn’t use that to play games anyways (unless you’re talking about pay as you go wifi plans or something). It is up to the game to give the warning, not Roblox, at least in my opinion.

6 Likes

You’re better off making your own chunk system. There isn’t enough flexibility to optimise it for your game.

1 Like

Extremely! On top of the benefits Streaming already supplies, you can stack those benefits with your own Chunks or loading zones to reduce content in workspace all together, minimizing your server load and your client load both!!

See here’s the thing, there IS a way to rely on :FindFirstChild, but it’s strenuous. First you have to compile your game, so that a constructor function can assemble your assets as their full instances. Second, you :PreloadAsync your compiled assets, only the ones in their most simplest forms, before the constructor receives instructions. Third, find a clever way to use your server logic to take as much of the burden away from clients as possible, and also make sure you have no data loss from the compiling! When you compile, you’re making sure to save things into ServerStorage first, then when the game boots, relocate that to MemoryStore or something similar!