A function that allows you to wait in milliseconds

(bootleg showcase)

do you have that seething annoyance in roblox’s systems not allowing you to wait in milliseconds? do you need that milisecond perfect time? well, fear not, i have made this system that allows you to do jsut that. although you may need to use this whenever needed, as it can result in problems that is locked to the roblox’s task scheduler

introducing (a botched) MilliWait() function!
which does exactly what it does, it waits in millisecond time.

local function MiliWait(Time) -- the time parameter is the amount of time you want to wait
	local NOW = os.clock() -- gets the current time when the function is ran
    local Time = Time * 0.001
	local dt

	repeat
        dt = task.wait()
    until os.clock() + dt >= NOW + Time
    -- task scheduler reliant
    -- will check the current delta time, multiply it by two, and check if
    -- the time is ahead of the expected end.
    -- if it is, it goes to the next line which does...

	repeat
        if true then end
    until NOW + Time <= os.clock()
    -- this, and will run this until it finishes the wait.
end

i haven’t really tested this out too much, but it’s most likely going to be broken by a bit due to lag spikes.
there is a chance if your computer is pretty slow, the task scheduler reliant algorithm will overshoot, and immediately run the resource intensive, performance reliant one. but i don’t know if this is actually true as well, so maybe test it for yourself?

if you wondered why there was a “if true then end” in the last thing, i have no idea, i just put it there so it wouldn’t be much of a problem. but this is pretty much not deep tested, so please if you could test it, show the results!

if you want to improve upon this, please send your solution in the thread!
i am eager to find new solutions to this problem. so thank you for your cooperation if you do wish to help me and the others.

By Shiroi.
(edit, i changed the code a bit for a performance boost)
(edited it so it takes in 500ms for 0.5s instead of 0.5s for 0.5s)

6 Likes

So uhh… given the name “MilliWait”, I expected it to wait the time given, in milliseconds. Instead, it seems to be in seconds. So, MilliWait(1000) will not wait 1000 milliseconds (aka 1 second), but 1000 seconds, effectively making it a slightly more accurate task.wait/wait.

Also, you could kinda do the same thing with task.wait(MS/1000).

roblox does not take ms as inputs, as the wait() function follows roblox’s “Framerule” or atleast 60hz, depending on your FPS. so no, and that is the point on why i made this post, because roblox does not take ms as a value

Neither does the function you’ve made???

Also, task.wait has replaced wait, which ran at 30hz. task.wait uses RunService.Heartbeat.

local function BasicallyTaskDotWait(YieldTime)
    local Yielded = 0
    
    while Yielded < YieldTime do
        Yielded += RunService.Heartbeat:Wait()
    end
    
    return Yielded
end
2 Likes

sir, i’m not sure if you actually understood what i said, and what i made.

image

task.wait()/wait() waits for the internal clock (sometimes by the framerate or 60hz which is shown as 16ms) before it can fire, it has to round up the value, or even longer due to system stress or throttling.

also, heartbeat does actually fire at 60hz, but it follows physics, which most of the time will be strained, for most uses. but it still isn’t accurate enough, you still miss about 16ms of delay, either late by about milliseconds, which makes synced things impossible to do without any lag compensation

my system utilizes task.wait()/wait() to reduce lag shown as the green line, because you wouldn’t want to do micro stuff in the entire duration from 0ms to the target ms

TL:DR;
task.wait()/wait() overshoots,
my system yields the thread till it is in the correct time.

1 Like

I was talking about this. The MiliWait function takes the input as though it’s in seconds, not in milliseconds as the name implies

AKA, I would expect MiliWait(1000) to wait 1 second, because there are 1000 milliseconds in a second, but instead, it waits 1000 seconds.

it was a writer’s error, i am used to roblox’s wait() that uses seconds.

so if i milliwait(0.5), will it be faster than milliseconds?

it would be cool to see deciseconds, picoseconds.

most likely, it sure is possible

This code doesn’t run faster than heartbeat. The least you can wait is your framerate. None of the code actually works to it’s desired purpose.
For example, if you do wait(0.01), it’ wont actually wait 10 milliseconds, but 16.6 milliseconds (assuming you’re running at 60 FPS):

local start = os.clock()
task.wait(0.01) -- We're trying to wait 10ms
print(os.clock() - start) -- 16.6666... ms assuming you're running at exactly 60FPS. As you can see, this is not 10ms
4 Likes

Oh yes it is

it does work on my testing though… it works too good, it actually does it in the correct timing (600 rpm or 10 per second)

also, please refer to this post A function that allows you to wait in milliseconds - #5 by reimakesgames

1 Like

This thread doesn’t even contain the right information. Just because you “wait” shorter (even though you don’t) doesn’t mean it’s better to generate terrain this way. You also stated that you shouldn’t wait like this in loop, which is literally what this thread is doing:

repeat
    dt = task.wait()
until os.clock() + dt >= NOW + Time

@reimakesgames task.wait runs after the heartbeat step:

And because heartbeat runs at your framerate, this function never actually runs faster than 60fps. This also means that this code would do exactly the same thing:

local RS = game:GetService("RunService")

local function MiliWait(Time)
    local start = os.clock()
    repeat
        RS.Heartbeat:Wait()
    until os.clock() - start >= Time / 1000
end

local start = os.clock()
MiliWait(1) -- Waiting 1 millisecond
print(os.clock() - start) -- 

If you just use the code above, it will do the same thing. It will probably run faster because it’s more optimized than what you provided. task.wait is basically a shortcut to RunService.Heartbeat:Wait():


As you can see in the video provided, it doesn’t wait 1ms, but 71ms.

4 Likes

Actually, I see my module faster than task.wait and heartbeat,

And heartbeat is still slow for terrain generation while my module is way too fast.

I have also benchmarked your custom wait function and it doesn’t wait the appropriate time much like roblox’s one when you try to wait a shorter time than the pipeline executes at

local function MiliWait(Time)
	local NOW = os.clock()
	local Time = Time * 0.001
	local dt

	repeat
		dt = task.wait()
	until os.clock() + dt >= NOW + Time

	repeat
		if true then end
	until NOW + Time <= os.clock()
end

local TaskWait = task.wait

local cachedTimes = {custom = 0, integrated = 0}
for _ = 1, 500 do
	local startTime = os.clock()
	MiliWait(1)
	
	cachedTimes["custom"] += os.clock() - startTime
end
warn("Custom Completed")

for _ = 1, 500 do
	local NewStart = os.clock()
	TaskWait(.001)
	
	cachedTimes["integrated"] += os.clock() - NewStart
end
warn("Integrated completed")

warn(cachedTimes)

16:32:15.619 Custom Completed - Edit
16:32:23.953 Integrated completed - Edit
16:32:23.953 ▼ {
[“custom”] = 8.463101300178096,
[“integrated”] = 8.33417210020707
} - Edit

It seems to me like your custom implementation is slower than roblox’s one as well as not completing what it is advertised to do

Where’s my module code supposed to be in the code?

Have you tried measuring that speed

At the top of the code snippet, I removed all the comments from it

local function MiliWait(Time)
	local NOW = os.clock()
	local Time = Time * 0.001
	local dt

	repeat
		dt = task.wait()
	until os.clock() + dt >= NOW + Time

	repeat
		if true then end
	until NOW + Time <= os.clock()
end

This? This is not the module code,

It should be as I got it from your post

EDIT:
Image is here: https://gyazo.com/7c5605d7069bd6c6cedd28a37db400aa