Custom wait - the best solution to yielding!

Resources Community Resources
#26

Hey all,
I’ve updated the thread with an explanation on why this module is actually important and good to use. I’ll copy what I appended onto the thread on this post:

Why should I use this, rather than default wait?

The main concern in a lot of Roblox games is that they use the wait function. Like, a lot. This is more bad than you may think. Firstly, this can clog up the task scheduler very easily, and deteriorate the state of your game very quickly. @Maximum_ADHD has demonstrated this issue, as seen here:

Yeah… Pretty bad.
So, how does this module address this? Simple! This module manages and sorts your yields to make sure there’s always only one wait running at once. This leads to making it practically impossible to clog up the task scheduler, saving your game from all the nasty issues.

TLDR This module makes sure your game will always have only one wait running at once, making your game not die from having a filled task scheduler.

6 Likes
#27

Hey there. I tested your benchmark (server and client) and I get
Num "failed": 15999 with your module and
Num "failed": 16000 with Roblox’s wait()

#28

This is an issue with having different hardware - I’m unsure regarding your computer specs, but my computer is pretty good and as such can compute more data efficiently, which leads to different results.

#29

I have an i7-6700 processor and 8 GB ram. Is that not fast enough? I’m sure most Roblox players don’t even have high-end devices lol.

#30

I’m unsure at this point. Using this code and putting it in a Script in ServerScriptService to benchmark provides me with the result of 0 failed on this custom wait, and 8302 failed on Roblox’s wait.
To benchmark, replace BenchmarkFunc = CustomWait with BenchmarkFunc = wait

#32

requireing works fine for me, but you need to add a wait(3) before the benchmark - the game hasn’t fully loaded if you run the benchmark directly after the require, which I assume is the issue

This code runs fine and provides the same results as previously, consistently. 
local BenchmarkFunc = require(script.ModuleScript)
wait(3)

local NumFailed = 0
for i = 1, 16000 do
	coroutine.wrap(function()
		local d = BenchmarkFunc(1)
		if d > 1.04 then
			NumFailed += 1
		end
	end)()
end

wait(1.1)
print('Num "failed":', NumFailed)
#33

Well, I am going to use this, I don’t knew about this issue, thanks for creating an alternative wait function for us!

1 Like
#34

Yeah, I’m getting inconsistent results but I guess everyone’s mileage may vary. Maybe my computer is too slow now :confused:
Thanks anyway.

1 Like
#35

Update [1.0.5]

  • Fixed some issues where the heap would sometimes not properly sort all active yields based on their priority (i.e time left to yield).
  • Source is now put on my GitHub, it is more trusted and also makes it easier for me to update.

I left some commented out debugs - you can mess around with the source with them if you want to, for whatever reason.

1 Like
#36

I’m back! This time the problem is the Wait not waiting the proper time, usually waiting longer than usual. Although I’m not advanced enough to understand how this works, I think the problem is relating to coroutines? Putting the wait function in a coroutine seems to cause the whole inaccurate wait time.

1 Like
#37

Hey, could you make sure you are using the latest version and provide a script which replicates this issue?
I don’t seem to experience any such issues. How long does it yield for?

image
image110×610 3.87 KB

#38

I probably made a mistake with something, since it works perfectly fine now. Woops!

2 Likes
#39

Update [1.0.5.5]

  • This module was using a max-heap rather than a min-heap… I’ve no idea how no one noticed this, especially me… All issues should be fixed by now. Sorry for my stupidity :sweat:
5 Likes
#40

Small issues that came with this update, Script timeout and sometimes refuse to continue due to this error.

image

#41

Do you have a repro for this you could send?
EDIT:
Could you make sure you are using the latest version? I’m unsure on how this would exhaust execution time when it’s supposed to do the exact opposite (i.e break the loop): image

1 Like
#42

I am using the last version, also there no Break function in this loop.

#43

The loop’s condition is PrioritizedThread - so long PrioritizedThread exists, the loop continues. By setting it to nil it would effectively stop the loop.

1 Like
#44

True, unsure of what causes it.

EDIT: These issues seem to come nearly at each wait, and timeout my loops when using it.

#45

A wait will quit working if I put it into a coroutine.
I do have all this stuff going really fast so that may be an issue.

Probably on me abusing the hell out of your wait system. :confused:
image

image

image

1 Like
#46

Could you provide a small repro. script which reproduces the bug 100% of the time?
This runs fine for me:

coroutine.wrap(function()
	print(BetterWait(1))
end)()

It’d be best if you printed like so: print("Done", BetterWait(1))

EDIT:

I found a repro. I’m looking into it.