Still no use, doesn’t wait for the amount of seconds I want.
local Run = game:GetService("RunService")
local function Pause(n)
local accumulated = 0
local heartbeat = Run.Heartbeat
while n > accumulated do
accumulated += heartbeat:Wait()
end
end
local start = os.time()
Pause(5)
print(os.time() - start)
You sure?
Worth noting that I also switched to os.clock so I could get a more precise measurement of how much time was being elapsed before and after the pause call, since os.time only returns whole seconds rounded. In all cases I’m reaching close to 5 seconds.
Ultimately not sure where you’re running this from or the specs of your device though considering Heartbeat is variable according to the current machine’s specs.
I used os.clock() and it just return numbers llike 4.7…, 4.5…, and not even close to like a 4.9 when pausing it for 5 seconds.
Could you give more information on your testing environment or your device’s specs? You could additionally check more variables in your script such as the DeltaTime being observed by the current iteration or your total time accumulation.
It is possible to create a custom wait and this is pretty much the way it’s done but it is very critical to note that point about RunService events being variable on the current machine. It’s certainly waiting 5 seconds for me but if not for you, some debugging is in order.
I’ve gone ahead and added some markers on the code you replied to me with:
local Run = game:GetService("RunService")
-- {accumulatedTime: deltaTime}
-- Check what the deltaTime was for an accumulated time point
local increments = {}
local deltaTimes = {}
local function Pause(n)
local accumulated = 0
local heartbeat = Run.Heartbeat
while n > accumulated do
local dt = heartbeat:Wait()
accumulated += dt
increments[accumulated] = dt
table.insert(deltaTimes, dt)
end
end
local start = os.clock()
Pause(5)
print("Time to run:", os.clock() - start)
print("Lowest delta:", math.min(table.unpack(deltaTimes)))
print("Highest delta:", math.max(table.unpack(deltaTimes)))
print("Exact increments", increments)
This is what incapaz used right?
local RunService = game:GetService("RunService")
local function wait(n)
n = typeof(n) == 'number' and n or 0
local spent = 0
repeat
spent += RunService.Heartbeat:Wait()
until spent >= n
end
Well, I had this other implementation:
(it just makes sure using os.clock, so it actually takes the certain amount of seconds, SINCE the wait was called, not since the last frame was called, if you want to use delta time from wait, or you’re messing with things that are important to respect to frames, use the function above)
local RunService = game:GetService("RunService")
local function wait(n)
n = typeof(n) == 'number' and n or 0
local start = os.clock()
local spent = 0
while true do
repeat
spent += RunService.Heartbeat:Wait()
until spent >= n
spent = os.clock() - start
if spent >= n then
return spent, os.clock()
end
end
end
Your issues are kind of weird? I’ve never seen anything like that happen to anyone.
CPU: i7-2630QM
RAM: 4GB
STORAGE: 500GB HDD
GPU: NVIDIA GEFORCE GT 540M
yeah it’s a 9 years old laptop
I got a bit confused about why you’re adding 2 tables for DeltaTime.
@LucasTutoriaisSaimo
I’ll try yours soon.
Debugging purposes: one is a dictionary, one is an array. The dictionary is meant to log what the deltaTime is at a certain point of accumulation (when Heartbeat fires) and the array is meant to collect all deltaTimes that have occurred in an array format for checking the minimum and maximum values that get assigned to deltaTime. This can help debug time issues.
Idk if this is still a thing but you can try clonetrooper’s thread 
Its got a custom wait function in it along with a few other things.
Weird, if I tried using in the command bar, it works well. In scripts, it doesn’t.
This actually works very well, but I am still curious how would I make one for my own.
Then consider reinstalling Studio and see if it fixes the issue. Have you tried that?
Hm. Maybe it might be some weird beta you have enabled?
DeltaTime is the time since the last frame was rendered.
Timer Starts > Frame Gets Rendered > Timer Ends
So if a client would be running at 1 FPS the DeltaTime would be around 1 Second because it takes one entire second to render a frame.
You want to add the deltatime. EX:
local AccumulatedTime = 0
game:GetService("RunService").Heartbeat:Connect(function(delta)
if AccumulatedTime > 5 then
print("Waited five seconds")
else
AccumulatedTime += delta
end)
Explanation: .Heartbeat fires every frame, and a new frame will optimally be created every 1/60 of a second. If for some reason, perhaps due to lag, your frame rate drops, a new frame may be created every 1/50 of a second, or 1/42, or even 1/23. You get the idea. Deltatime is the time between frames. If your framerate is low, deltatime will be higher. By adding deltatime, you can correct time lag.
However, if you have a very low framerate then by the time .Heartbeat fires again, time will have passed and you will have overshot.
Why are you even trying to make a custom wait function??
Right, I forgot to mention the fact that Roblox’s global wait() function is unreliable in big game structures and big codes.
Weird, maybe I’ll try to test it in a real game because I only test it in studio the whole time.
Thanks! I’ve found what I want for my in-game animated intro, but how can I use it ? I put the script inside a modulescript in ServerScriptService
you require the modulescript via require()
then as usual
local modulescriptname = require(LocationOfModule)
modulescriptname:Wait() -- the amount of time you want to wait.
So, sorry for the bump, but one thing to note is that DeltaTime is let’s say, … weird, when a session lauinches, if you wanna not have an issue with that, you can try doing Heartbeat:Wait() twice and seeing if that helps, before executing wait.
This was probably why you were having issues in the first place.
I recommend using DeltaTime solution opposed to using os.clock solutions most if not all the time. Especially if you’re working with UI or anything that’s using a RunService event really, anything client wise basically.
os.clock solutions don’t suffer from this issue but they aren’t great.
The problem is that frames don’t actually start rendering after a pretty good amount of time after the session actually starts, therefore you get these 4.5 numbers, the first frame messes up the rest.
I recommend you look into this reply for better understanding.
I actually even suspect Roblox’s wait might be doing this as well. (not task.wait)
A normal DeltaTime based solution will pretty much always return way higher differences for much time it says it takes, and how much time it actually did than what’s seen above.
