Im making a Magma fruit from one piece and the magma dripping needs burn damage to happen every few seconds. How do i do that WITHOUT using while loops?
Use while loops
for i = 1, -1 do
<your code>
task.wait(.5 ish seconds)
end
1 Like
People have a script instead of asking others to do it for you
i will be calculating other stuff like dripping and object tweening, how do i put it in a new thread
A while-loop shouldn’t provide much difference from other kinds of loops. If you want a definite end, you can use a for-loop.
To create a new thread, you can use
task.spawn(function()
end)
2 Likes
I was just typing this out also. task.spawn that if you need to move on in the script.
The most common way, in Roblox as well as pretty much any AAA game with these sorts of time-based status effects, is to have a data structure (e.g. a Lua table) keyed by the entity reference (e.g. player, player.Character, player.UserId, some index you’ve given each entity, etc… whichever is most appropriate) which stores what status effects are on them, with an expiration timestamp.
Then, on a RunService frame-based event, most commonly Heartbeat, you check all currently-live status effects and either ‘tick’ them (apply their damage per tick, or damage per second * elapsed time), or expire them if they’ve expired. You can use tick() or time() in server scripts for timestamps, as long as you’re consistent.
Typically, ticking active status effects is just one of the things a game will commonly do in an every-frame update function. For very long duration events, you can check less frequently by accumulating elapsed frame time in a variable until it gets past some threshold, like if you want something to only check every half second or so, you can have a structure like this:
local accum = 0
RunService.Heartbeat:Connect(function(dt)
accum += dt
if accum > 0.5 then
-- do some thing you want to do every half-second
accum -= 0.5
end
end)
Note that when accum exceeds 0.5, you have a choice of 3 things you can do:
- Subtract 0.5 from it, as I’ve shown. This allows it to accumulate overflow, so that the average frequency over a long period is twice per second, understanding that if accum gets to be over 1.0 from long frame times, it may execute on successive heartbeats to catch up. Likewise for other multiples of 0.5.
- Set accum back to 0. This will result in the code running at roughly 2 times per second, but it will not try to catch up if there are laggy frames, there will always be at least 0.5 seconds between the code executing.
- Use a
while accum > 0.5 doloop withaccum -= 0.5inside, instead of just an if-then. This is a variant of option 1, but will do all the catching up withing a single Heartbeat.
3 Likes
As your game gets more sophisticated, you may run into some issues if you try to move the updating of a status effect into its own coroutine (including task.spawn). The issues that might arise are that you may have multiple sources of damage on a character, which you ideally want to process in a very specific priority order.
For example, if on a given frame a character takes damage from opponent A’s burn, opponent B’s poison DoT, and also a direct attack from opponent C, there may be interaction between these as well as priority order. For example, you might want to prioritize the direct attack for who gets credit for the kill, or if it’s all just DoT, you might want to give credit for a kill to the first DoT that was applied. You might also want damage effects to not simply stack linearly, maybe one takes priority or maybe there is a diminishing returns calculation where effects stacked after the first are not at full strength. Lots of options here. When I worked as a game engineer on popular competitive MOBA, getting this exactly right was a very big deal.
In any case, this is why I tend to go right to considering all status effects in a single on-tick update function, in a single thread, so that all the ordering is explicit and consistent.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.