Also no. They’re in a normal script, or global script.
Thanks. Tween service works and removed the lag slightly. Still unfortunately having some issues though.
So do it inside a localscript and compare the difference
This is not true
This is also not true, using
wait() does not cause lag. Although I still suggest using
RunService.Heartbeat, or switching to
wait() is now deprecated in favor of
Tween service is the same thing, just has more customization. It’s still changing the CFrame rappidly though.
Moving that amount of parts shouldn’t be causing the lag unless it’s huge amounts of them.
I suggest looking through other scripts you may have in your game and providing more details.
If you are moving a large amount of parts, then I suggest using a local script and only moving parts that are within a certain distance to the camera.
You can always use tweening, but if you do, I suggest using it on a local script so the server doesnt have to replicate it.
Feel free to ask if you need help with any of these
Okay so, I notice that the heartbeat movement is recommended. However… how do I make it move using RunService? CFrame? Position?
Here’s what it may look like:
-- On a local script. You will have to modify this since its psuedo code local RunService = game:GetService("RunService") local PartsToMove = workspace.Parts:GetChildren() -- How ever you want to get the table of parts RunService.Heartbeat:Connect(function() -- This will go off every heartbeat for _, Part in pairs( PartsToMove ) do -- Get all the parts in the PartsToMove table -- You could always check the parts distance from the camera so you only move parts close to the camera Part.CFrame = -- How ever you will modify the cframe end end)
Thank, I will remember that.
Okay so… with the tweening… I tried it and… it worked. The game is playable now… but the game still lags kind of badly… so I’m going to try run service now
Also… why is the part not moving straight? It’s literally moving to the right, when it’s supposed to go straight. The axis is Z, not X. So not sure why it’s moving like that. (This is with the tweening)
body velocity is Deprecated, I think its linear velocity, I’m not sure or angular velocity.
This usually happens when cloned parts are parented to workspace at the same time, I think you should just use a for I loop and parent the cloned parts one by one slowly and do a task.wait. (This isnt fast sadly)
Make Meshes instead of Parts, unions etc…
I have. It’s a script issue or something.
Limit the number of parts in the Workspace at any one time. If possible, try to keep the number of spawned parts to a minimum.
Avoid having too many scripts running at the same time. Be sure to delete any scripts that are no longer needed.
Reduce the number of lights in the game. Lights can be a major source of lag and should be kept to a minimum.
Reduce the number and complexity of textures used in the game. Textures can also be a major source of lag, so be sure to use only the necessary textures.
Limit the number of sounds playing in the game. Sounds can also cause considerable lag, so be sure to keep them to a minimum.
Optimize the scripts used in the game. Take a look at the code and try to see if you can find any ways to make the code run faster.
Make sure all assets used in the game are optimized for performance. Try to use assets that are as small and efficient as possible.
Use a server-side solution to reduce lag. If your game is hosted on a server, you can use a server-side solution like a CDN to reduce lag.
Try running the game on a different platform. If you’re running your game on Roblox, try running it on a different game engine, such as Unity or Unreal Engine.
Make sure you’re running the latest version of the game engine. If you’re running an older version of the game engine, you might be missing out on important optimizations.
Try to avoid memory leaks.
Try to use MeshParts instead of normal Parts.
What speed is this script moving at?
The nice part of switching between using CFrame and Roblox physics is that you can adjust the “quality” of CFrames. If you’re running these CFrames every heartbeat (1/60th of a second) I suggest toning it down to 1/30th of a second and see if there’s a decrease in lag.
Sorry for such late response, I figured this topic died to be honest. The CFrame speed was at 1.5, or 2 I think. Also, I do not know how to use RunService, so I used a for loop.
All good, @baseparts above sent a RunService example that I think sums up how to use it really nicely. If you’re still up for optimizing your code, read below!
Can I see your code? I’m a bit confused on what this means.
local RunService = game:GetService("RunService") local Buffer = 0 RunService.Heartbeat:Connect(function(DeltaTime) if (os.clock() - 1/15) - DeltaTime < Buffer then -- Runs every 1/15th of a second. If the 1/15th of a second threshold hasn't been passed, it'll just return the heartbeat, which means nothing past it will run. -- You can change 15 to any number. If you change it to 60, it'll be performing like a normal heartbeat. As heartbeats only run every 1/60th of a second. -- If you change it to 30, it'll look similar to 60 but if you focus on the CFrames they will look ever so slightly "choppy" -- If you change it to 15, which I recommend only if you have a lot of parts, it'll look choppy but will still look somewhat normal. -- Obviously you don't have to stick to these numbers, but they're here as a guide. return else -- Everytime 1/15th of a second has been reached, it will reset the clock and wait for the next 1/15th of a second. Buffer = os.clock() end -- Do code with moving CFrames here. end)
Buffers are important in this case when you don’t need to run it 60 times a second, which I doubt you need to unless you want extremely precise hitboxes or calculations for whatever you’re doing. Using this code and setting it to 1/30th of a second should optimize it well enough, as it’s basically cutting the workload in half.
If you could post your code I could try to package it all nicely together.
This code was already at 29, but here it is again.
local Speed = script.Speed
for i = 1, 250 do
script.Parent.CFrame = script.Parent.CFrame * CFrame.new(0, 0, Speed.Value)
I’m a little late to the party but…
You could use a lag reduction service such as StreamX:
You can check the part counter.