You could probably use RenderStepped, as it would execute before a frame renders - but I recommend using Stepped regardless, as it executes before physics renders, keeping it more consistent with the rest of the game. Corrected by colbert2677 - I recommend checking out his reply
1 Like
Getting back on topic, you don’t need to use RunService - wait(n) is fine to use as long as you’re careful with it. It comes down to the simple question: how often does my code need to execute? Every second? Or every other second? Answering that simple question will give you an idea of how often your code actually needs to execute.
1 Like
while wait(n) do is not a bad practice. It’s valid. People are just saying that it’s a bad practice most of the time since it doesn’t make sense that “while the wait duration is truthy do”
while true do end is objectively better than the while wait() do end. The former is clearer and clearly indicates that the loop is infinite. This is out of the scope of the OP though; so if you want to learn more feel free to dm me and I’ll happily explain in-depth.
I’ll also leave this.
1 Like
Welp… after reading everything I feel the same… I like to use RunService everytime I can but I always feels that is more demanding because is firing each frame. But everyone says that is better due to the exaust the wait causes…
So… I dont get why… So executing an expensive loop 60 times in a second is better than just execute it 1 per sencond?..
This is because he wants it constantly check and don’t wanna have an exhaustion. Using while wait(1) is pretty bad since it only detects every seconds.
1 Like
wait(n) is fine to use - it’s wait() that creates issues. RunService’s events (HeartBeat, RenderStepped and Stepped) executes with physics rendering, it doesn’t quite have the same problem wait() does.
To reiterate something I said prior,
2 Likes
Thank you for ur answer!
How low in seconds can create exhaustion? Well surely depends on the code that is looping… So no answer… if Im using a wait(0.1) then it would be better to use RunService right?
1 Like
Thank you so much for ur answer!
I think I kinda get it… Everything depends on the system. The needs of the system, if I really need to update something faster than 0.5 seconds maybe? Would be better to use RunService then?
Pretty hard to understand… cause it will surely depend on the expensive of the code to be looped and the system requirements, I guess… a balance I guess…
wait(0.5) would be fine to use - however, if you’re super concerned about it causing issues, you could use RunService’s Stepped event and use a counter to keep track of execution time.
local Counter = 0; -- Counter to track the time
RunService.Stepped:Connect(function(_, Step)
if (Counter >= .5) then -- Has the time reached or is greater than 0.5?
Counter -= .5; -- Subtract the time
print("I execute around every 1/2 a second!"); -- Output text
end
Counter += Step; -- Add step time to the counter
end);
2 Likes
mmm very interesting, I saw examples like yours before, but I never took the time to understand it… I could call that an hybrid? xD
BTW makes totally sense! Thank you so much for your help! :3
1 Like
That can be almost the same time as using RunService. Creating an exhaustion will be using while true do loop.
1 Like
Yup, if the time is pretty close to RunService, then use RunService sounds better deal, I think.
So u mean a loop that never ends? turn it off and turn it on helps?.. mmh I need to learn a lot more, and more. Understand exactly what is cause exhaustion to the script. I shouldnt have skipped that post about it… Anyway, I will get it eventually
Thank you!! :3
You can only stop a loop using break.
I just meant, while false do or break, when ur example was while true do, I thought that exhaustion is caused cause the loop never ends and after certain amount of time could fail or something. Thats what I meant I need to know exactly what is exhaustion. I though it was something related with the amount of data a device can solve and not able to follow the speed of the loops
before*
If physics are not critical to your system, then use Heartbeat. Stepped is only useful if you need to run code per frame before physics simulation occurs. For example, you may be creating a custom physics engine or need to run a piece of code that acts on parts before their physics update (car collision, lowering player velocity on the Y-axis after a long fall to prevent them from falling through floors, so on). Heartbeat is standard, or should be.
before a frame does*
Never use RenderStepped if you aren’t sure you can update your code within less than a small number of ms, meaning a camera or character update. RenderStepped can block frame execution if you run expensive code. It should be used very sparingly.
2 Likes
So overall,
I should be using RunService as loops exhausts code, and I should be using RunService.Heartbeat or RunService.Stepped as it ratios depending on a device’s capability (example a low end device with 30 FPS will fire 30 frames a second).
I want this code to be all on the client. If what I have learned from this post is correct then while wait(x) loops exhausts scripts more then RunService, and I should get into the habit of using RunService for loops I want to happen fast?
Anything else I should note?
Question: where does the exhaust part come from? I didn’t really read everything above but this exhaust thing doesn’t exist. It might be referencing a timeout event which your loop stops running if it hits the timeout, typically representative of a long loop not having any wait between iterations.
RunService is better because it makes your functions execute on a frame-by-frame basis. It passes the time that elapses between frames so you can use that to your advantage (might especially need that time because FPS unlockers or slow clients can cause the time to be smaller or larger). Your code can also run predictably, whereas you need to be concerned with the scheduler for wait. Bonus round that its frame functions are provided as events, allowing you to achieve an event-driven system.
Heartbeat is a recommendation but not a necessity. The needs of your code change based on what exactly you’re doing, though often there’ll be a better event-driven alternative out there to loops, the latter of which should be used sparingly.
Again, not sure where this concept of exhaustion comes into play, but it’s something you can probably ignore. Support threads tend to give incorrect, misleading, unsubstantiated or weird advice and this is one of those things. Don’t focus on “exhausting”. RunService can often be a better substitute than a while loop for most cases.
The last thing you should note is that using wait as the condition of a while loop is bad practice or rather a gateway into bad practice and you should avoid using them in code. Someone linked a thread I had up about them but just to link it again:
3 Likes
Alright thanks for the info! I’ll use RunService as an alternate for while wait() do for the reasons you provided.
Once last question (if you don’t mind):
Let’s say I had a bar that increases the X size .0001 every frame using RunService.Heartbeat. Will the speed of the bar rising increase if someone had an FPS unlocker? Or vice versa, will the bar slow down if someone is on a low-end device running with 30 FPS?
Yes.
When the RunService events fire, they can provide the approximate amount of time that has passed since the previous frame, so you can use that to increment the value more precisely.
So if you want a value to increase by some amount every second, you would do it like this:
local value = 0
local rate = 0.006 -- your example (.0001 units per frame x 60 fps assumption)
game:GetService("RunService").HeartBeat:Connect(function(dt)
-- (units / second) * (seconds) = (units)
value = value + (rate * dt)
end)
Keep in mind that if you use the Stepped event the parameters are a little different:
local value = 0
local rate = 0.006
-- first parameter in Stepped is the time the physics engine has been running
game:GetService("RunService").Stepped:Connect(function(_, dt)
value = value + (rate * dt)
end)
2 Likes