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.
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
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.