Thats the reason why people use Wait()s for loops because they run so fast.
No. wait() should be avoided as it relatively expensive in some cases. You can write a custom wait() and it could be even faster.
sorry for causing alot of trouble, im not an expert in loop speed and physics simulation 
Oh don’t worry, no problem with you.
So it seems runservice.Stepped is working slightly better. I also simplified the code so I guess thats a start
Wait() may not always yield the specified time. It depends on the machine that’s processing the function.
Creating a custom wait with RunService.Stepped would be a more accurate way of waiting a certain amount of seconds, as deltatime can be used to increment the timer. (The time between the last .Stepped call and the current call.)
2 Likes
I agree with you. Smart guy^^^^^^^
2 Likes
I have a question, does setting a parts network owner allows u to modify it on the client and it shows the same on the server? If not I will stick to using Stepped on server
Setting the NetworkOwner only specifies which machine will process the object’s physics. This was implemented to take off some of the server load.
You may notice in some games, when a projectile passes by certain a player, it may lag for a bit or seem to move differently. That is caused due to the server relying on the closest client’s machine to calculate the physics for that object as it passes by. Then, the server replicates the results.
Setting the NetworkOwner to nil indicates that the server will always process the object’s physics. You’d want to keep the server processing an AI’s movement for example, as it will be consistant. If not, then the AI will start moving in weird ways when it gets close to clients. As their machines will take over the physic’s processing.
So if that’s the use, then it is perfectly fine using Network ownership to position parts and everyone would see it move in the server also, If so this is exactly what I need
Well, not necessarily. You’d still need to replicate any changes to the server if done by a LocalScript (On the client).
Other than that, the client’s machine will only calculate the object’s physics. Just as the server would. The only difference is the server does not have to do all the work. It just displays the results that are returned by the client’s machine.
I understand. I will try to experiment with this to see if it works as good as I think it does
You can make it faster by adding an interations variable:
local maxIterations = 5 -- It will run the loop this many times before waiting
local iterations = 0
while true do
-- code
iterations += 1 -- Adding onto the iterations
if iterations == maxIterations then -- Checking if the threshold is passed
game:GetService("RunService").Heartbeat:Wait() -- Waiting
iterations = 0 -- Resetting
end
end
Although, this may not be beneficial to your use case(s).
Any iterations faster than that will possibly crash so why would you want to do that? I guess if you want faster iterations then don’t use wait?
A much easier to code way which I personally use in my setup code in my render engine is
local i = 0
for x=0,width-1 do
for y=0,height-1 do
i += 1
if i %1000 == 0 then
game:GetService("RunService").Heartbeat:Wait()
end
end
end
looping infinitely with a for loop would be:
for i = 1, math.huge() do
end
Running some tests; I have found that a for loop is the fastest.
My proof would be:
The code is 30 lines long everything lays in the loop. The while loop is slower. The repeat until loop is equally fast but only on a smaller scale, as things scale up, it may get slower.
Take this with a grain of salt, as all of my proof could be proven invalid at any time.
1 Like
You know it really isnt that hard if you want a faster loop then add a loop inside a loop or a run service inside of a run service think smarter not harder 
1 Like
try this out
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.