Avoiding wait() and why

I’m aware. But, it won’t ever be done. In that scenario, players should continue receiving money every second forever, so the connection would never need to be disconnected.

1 Like

While the heartbeat method has more overhead (in terms of code you have to write and manage), I would still prefer it. It would also let you sync to the second more properly without drifting at all (but you’d have to redesign it a little bit).

4 Likes

Just came here to add that @Maximum_ADHD did a funny but yet interesting experiment on this:

5 Likes

I understand the instability of the usage of wait(n)'s for the clients. However, with all of the replies, this caused some confusion in me. Does the same apply to the server-side scripts, and wouldn’t repetitive calculations with .Heartbeat throttle the server?

1 Like

Yes. The throttle exists for both sides.

No.

2 Likes

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.

RunService (roblox.com)

3 Likes

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

As much as I’d like to agree with you, some other’s don’t.

Check this article out. Spawn is evil

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.