Hey !
Can’t I execute many delay at same time ? Just look at this screen :
After delay is just firing 1 time instead 2 times.
Because you are executing the event again before it finishes…effectively resetting it. The event doesn’t stay in the delay queue when the event is called again.
The way I work around this by adding the script to the BeginPlay of an empty actor, named “B_DelayTest” for instance… In your example, EventBeginPlay → Print string(“Before Delay”) → Delay(5) → PrintString(“After Delay”) → DestroyActor(Self) and “H” would be bound to: SpawnActorFromClass(B_DelayTest)
There is likely a better workaround but this gets the job done for me.
1 Like
I think Delays actually get ignored when hit again, not reset. Timers get reset. But ya, that IS why it’s only firing once. You’re running it again before it finishes.
Okay thanks to everyone for answer me :). I’ll try to do this with a timer or try the Sadonis’ solution.
Thanks again 
This is correct, delays ignore any additional execution after they have been fired and only start listening for execution again once they have finished their delay.
There is an additional RetriggerableDelay node that has a particular property you might find interesting.
You folks love to use delays then complain that games use single core of CPU. Well everybody likes to use delays because it is simple.
Instead delays you need to use timers, but they are dangerous to use because of their text referencing, if you mess that later everything goes kaput.
For delay execution i made simple function (its basically what timers do):
When i want to call timed (delayed) event i “get game seconds”, then add to that delay in seconds i want.
So now i have time in game seconds when my delayed execution should happen.
I set this value to some variable lets call it: “delayed event time”
Now on event tick. i check if “game seconds” is greater than “delayed event time”
If so i set “delayed event time” to some very big value (or to negative, but then check for negative to execute condition)
Then i execute delayed stuff.
That checking for delayed timer and if i should execute or not may be packed into nice function. You need to feed it with your “delayed event time” variable reference. Works better than timers for me, as i can decide if i want to use game seconds (which can be paused), or real clock seconds. It is also safer, and harder to introduce strange errors.
timers==timelines?
hmm?
Imagine scenario (its when i decided no more timers):
You create 5 timers to manage all your timed tasks.
At some point you decide that “decrease health for DOT effects” should be renamed to “Damage Over Time” for simplicity.
So you rename your timer.
Now 20 or so nodes that reference your timer by text name “decrease health for DOT effects” are not working anymore because now they should reference to it as: “Damage Over Time”
You manage to find 19 of them (search for nodes is also ****/non functional in blueprints)
Because last (20th) name is not changed you get weird errors that you cannot trace down to node.
Yes you can put that name in global variable (wait you CANNOT do global variables in blueprints), so you place that in player controller variable (wait then how you manage timers that work for every player), so you place that variable name in function is some function library. But with such hassle my method is not that much more complicated, and when you rename function name it will rename all nodes. So why bother with timers?!
PS. Timers are timed events implemented by epic for blueprints. They are nice, but very easy to introduce some random errors, as my above example shows.
Thanks for clarifying…I think I messed up my syntax:) By “reset” I meant that the execute chain is restarted when fired again, cancelling any in-progress actions…Not that the delay itself is reset.
i had this error yesterday, for some reason it happens sometimes, not always, one timeline ive renamed like 3 times and everything ok, another one i renamed once and it broke .
Wow, thanks for this solution ! This is working :).
Thanks again 
That’s good stuff right there, I did not realize that Delay’s worked only a single core. You are right though, they are super easy to use and very convenient.
It makes sense that delay would only hit one core.
But I don’t see the problem with timers, especially if you link directly to the event being called by the timer, rather than calling it by name.
Event tick might be practical for really short intervals but wouldn’t a timer be more efficient for anything with a few seconds or more?
I could very well be wrong but I designed my game almost entirely without even using event tick. My game has been tested on devices slow as 1.2ghz dual cores and it runs very smooth with virtually no impact on the battery drain. Granted, with all this said my project is a Paper2D game and I made optimizations way beyond just getting rid of event tick.
Your mentioning of pausing game time and not having the delay affected is however a valid concern. Since I don’t use event tick I really haven’t had a need to pause my game but given what you said I assume timers would continue to tick even when paused? With the random errors you mentioned, that can all be avoided with proper cleaning. It might be extra work but it’s the right way to do things. Threading has always been a little tricky but super useful when you get it down.
I guess what I’m trying to say is: I do not think timers are that bad at all when used right.
For timers, a safe(r) way to use them is to use timer by event, rather than a timer by name (string) reference. I think I remember reading a commit at one point where they were planning to remove the by name (string) version, but apparently it didn’t happen.
Timers are great =)