A function that allows you to wait in milliseconds

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

well try repasting my code and measure the speed

Uhh dude, not her module, my module.

Your module isn’t actually a wait module as it doesn’t yield the thread at all, so if you were to put it into a while true do it would crash studio( like it is doing to mine right now), you’d be better of not using it at all as there is no way for it to wait until a specified time has elapsed and no other scripts would run at the same time as the thread scheduler will keep running this thread until it crashes.

also I thought you were this post’s creator and you shouldn’t be plugging you’re own post in another person’s post

1 Like

To me it does. I can show proof later

Try to mess with the second argument, you’ll see a difference

10 times per second is easy - you can do that with task.wait(). Try doing it 200 times per second. It won’t be able to do it properly, since it’s still based on Heartbeat.

why do you keep saying heartbeat is still slow for terrain generation? are you doing this?

while true do
  for y=1,200, do
    for x=1,200 do
      --perlin code
      task.wait()
    end
  end
end

maybe instead of spamming wait() to “garbage collect” how about you decrease your space complexity to avoid running out of memory (or just turn off script timeout lol). How? well how about making it one loop, saves LOADS of ram usage. Also, please don’t tell me you are doing some crap like this

for y=1,200, do
    for x=1,200 do
       local perlinNode = Instance.new("Part")
       --[[
        perlin properties
        ]]
        perlinNode.Name = tostring(x).."."..tostring(y) -- uh oh
       perlinNode.Parent
      --perlin code
      task.wait()
    end
  end
while true do
  for y=1,200, do
    for x=1,200 do
      local perlinToModifyPosition = workspace[tostring(x).."."..tostring(y)] --kms with this datamodel overload
      --perlin code
      task.wait()
    end
  end
end

instead, use a god damn hashmap! (fancy word for dictionary)

sorry if i seem harsh but i have experience in doing computationally expensive stuff like that in roblox