Sorry for the dead topic revival, but I’d like to address a big warning.
Heartbeat, RenderStepped and Stepped have been deprecated. As such, I highly recommend that you use PostSimulation instead of Heartbeat and PreSimulation instead of Stepped.
Thanks for the update, I didn’t know this.
Edit: Roblox has not announced these updates yet, so continue using these until a proper announcement from Roblox. Also, Deprecation does not equal removal.
1 Like
Should I avoid wait() that has a number inside or just wait() without any number inside?
1 Like
He already mentioned it in the post:
2 Likes
Hey, don’t abuse the humble wait() >:(
In all seriousness, I do agree with the majority you’ve said.
However, wait() is still very useful for testing out code before you put in anything complex just to get a feel of what they do.
If you want to use a while loop rather than runservice just to check something, wait() is much simpler to type and see.
Overall, wait() does have its place in coding, else it would never be around. I haven’t had many opportunities to use :Wait() but after reading this post, I definitely will make more use of it!
1 Like
Wait, aren’t you supposed to write a function in a modulescript as (module).(function) not just (function)? You’re just writing “wait” instead of module.wait, right? Or am I just stupid
No…modules by default just happen to return tables since you are most likely to write a code library using them, so you would store them in a table. Code libraries have several functions to use. This one just returns a single function, so it is fine to just return the function.
functions can be stored in the module table? whats the difference between putting them outside versus putting them inside
If your module has only one function, and that won’t change, there is no need to have a table instead of just giving the function.
-- Module
return function() end
-- Script
local func = require(path.to.module)
-- instead of
local func = require(path.to.module).func
Although, it’s probably better to just have them in a table since you never know when you might add another function to the module.
1 Like
Couldn’t you also use custom signal classes like Quenty’s signal class as an alternative to using bindable events? After all, creating a new instance is somewhat expensive, as opposed to creating a signal.
Creating a new instance isn’t expensive, so there is no point.
local before = os.clock()
for i = 1, 1000 do
Instance.new("Part", workspace)
end
print(os.clock() - before)
After a 1000 iterations: 0.0111
Just a reminder to not use the second parameter of Instance.new() to set the Parent.
This comes with a citation, only if you aren’t setting the properties of an instance. In the code, I’m not setting any properties so there is no problem with using the second parameter of Instance.new.
6 Likes
That’s a really interesting way of optimizing code. I’ll try it out soon enough.
Sorry for bumping again
How would I replace this piece of code?
local c = 240
coroutine.wrap(function()
repeat wait(1)
c -= 1
until c == 1
end)()
repeat wait(1) until c == 1 or ReplicatedStorage.Values.PlayersLeft.Value == 1
local ready = Instance.new("BindableEvent")
delay(function()
ready:Fire()
end, 240) -- I forget if it's delay(240, function() end)
ReplicatedStorage.Values.PlayersLeft.Changed:Connect(function(newValue)
if newValue == 1 then
ready:Fire()
end
end)
ready.Event:Wait()
2 Likes
looked it up to make sure and yes you put the time first
I agree with this, but what about using it in the context of wait(5)? Do I have to create an intricate RunService.Heartbeat:Wait() solution such that I repeat that 300 times?
It says right at the top of the post.
Let’s talk about
wait(). Notwait(n)(although if you are using smallnvalues to where it’d be barely distinguishable fromwait(), you’re probably going to hit the same issues mentioned in this thread).