I’ve seen people like :
Make draw distance scripts to prevent lag. How do they do it and would there be any problems with it?
I’ve seen people like :
Make draw distance scripts to prevent lag. How do they do it and would there be any problems with it?
Might be wrong, but doesn’t StreamingEnabled do this?
Whats streaming enabled?
But is there any problems while using it?
The wiki article lists the problems and restrictions.
Wrong: StreamingEnabled is finnicky and not as smooth and nice as Ripull’s system.
You could possibly split the workspace in zones.
If you’re close to a zone, go through it’s contents and load stuff that’s close-by.
*Not splitting on zones could possibly lead to more lag than you’d have with just letting it be regular.
How would you do that? I think you have to do something with magnitude but of course, I’m not a scripter
Do you have a scripter on your team? Creating a draw distance script is an advanced matter and there are no open source ones that come to mind.
Does anyone know if this would work for scripts failing to run due to large amounts of bricks? In a group that I work in, there are scripts used that seem to only work under a certain amount of bricks. Of course, on the higher end computers, the scripts load just fine, but on most, they are unresponsive. I’m wondering if this “StreamingEnabled” would be the solution to the issue I’m facing. Please let me know if you think this would help me.
The amount of parts in your place do not correlate to code not working. If you’re using StreamingEnabled (which you really shouldn’t), you need to account for parts that have not been streamed in on the client. The server will always see all parts however.
Generally the way I create draw distance scripts is I keep a table of BaseParts in the workspace (filter GetDescendents and DescendantAdded) and then I loop through the table every 10 or so frames. To wait for x frames you can call RunService.Heartbeat:Wait() x times. Inside of my loop I check the distance of the part to Camera.Focus. I use Camera.Focus for this because this is actually what Streaming enabled uses I believe. Finally, if the part is in distance I set it’s LocalTransparencyModifier to 0 or set it to 1 when out of distance. I use this property because it doesn’t interfere with Transparency and is only used by Roblox’s camera scripts.
Edit: I read one of your previous posts… You would use Magnitude to get the distance. (Vector1-Vector2).Magnitude will get you the distance between two vectors.
If you mean chunk loading with this, I don’t advice creating a script yourself. There will be lag when a player loads into a new chunk because all the parts would need to be inserted/removed into the workspace at the same time. There isn’t really a work around this and that’s why you should use streaming enabled instead of a custom script.
Or just use LocalTransparencyModifier like I suggested… There is no reason to remove and insert parts (this will cause replication issues and lag)
StreamingEnabled isn’t going to help you with the number of dynamic assets that are in the example video.
For starters, you want all of these dynamic objects to exist exclusively on the client. The moving trees and the abundant grass don’t serve a vital role in the gameplay interaction between players, and thus you want to make sure the server isn’t wasting any resources on them.
The grass seems to be built out of various transparent textures spread across the map. These are probably split up in regions (chunks) and loaded in when you walk near, or generated automatically based on the terrain geometry.
The trees are most likely created by having the client clone tree models to “anchor points” that mark the positions of trees across the map. Using simple magnitude checks, you can define whether to load in a low-detail version of a tree, a high-detail but static version, or a dynamically animating model. You can change these ‘render distances’ per platform, so a mobile user would never see high detail models unless they’re standing within X studs.
In other words, to make worlds with this scale you are not making scripts to prevent lag. Instead, you are approaching your world building and game architecture structurally different than most Roblox games out there. This required careful planning and solid knowledge of how to work within the client-server model.
That’s strange as this is exactly what’s been happening to me — when I remove bricks, the scripts suddenly work again. Do you have a suggestion of what I should do?
I don’t know what your situation is like though. You haven’t listed anything you’ve tried, including checking the Developer Console for potential errors. I don’t know how many bricks you have. I don’t know what your code is doing. Your vague replies leave me with little to work off of.
Simply changing something’s transparency won’t help the lag caused by
StreamingEnabled does do a pretty good job, however, especially when you have a lot of parts in a small area, it won’t help much.
A draw distance script doesn’t have to be complicated and perhaps you could learn a bit of scripting or get a friend to do it. The basic premise is to store part data as raw data in your script, and then “loading it in” (instancing the parts) when they are needed. Here’s a oversimplified example:
local grass = --reference to a default grass model
local grasses = {
{pos = Vector3.new(1, 10, 21), part = nil},
{pos = Vector3.new(10, 0, 0), part = nil}
}
--Theres a few approaches you can take to optimize this, but a simple loop can work.
while wait(.5) do --We want to refresh the parts quickly to optimize user experience, but not too fast to cause lag.
for _, inst in pairs(grasses) do
if inst.part and DistanceBetween(inst.part, playerCharacter) > RENDER_DISTANCE then
inst.part:Destroy()
inst.part = nil
elseif not inst.part and DistanceBetween(inst.pos, playerCharacter) <= RENDER_DISTANCE then
inst.part = grass:Clone()
inst.part.Position = inst.pos
end
end
end
This can be improved by generating a list of parts from what is already in your place, making specific render distances for each type of prop or anything to make the inside of the loop more efficient.