How do I run the same event multiple times independently of each other?

When I run my event, it starts with a delay. When I run the event a second time, the run is ignored because of the delay. Is there a way to run it a second time but with a different instance or create events at runtime? I tried the set timer by event but it does not let me have inputs on the event.

1 Like

Can you explain what you mean by having input on the event?

In any case, to run Delays individually you need to have individual instances of the same code, so running a Delay node several times in one blueprint is impossible.

As for timers, in C++ it wouldn’t be difficult to make an array of timer handles, find one that isn’t active, and run a timer with it, but unfortunately in blueprints I haven’t found a way to use TimerHandles without setting a bunch of timers first, so if someone could prove me wrong that would be great.

One solution for your case is: create a separate blueprint with your delayed function. When you need this function, spawn that blueprint and have it do its job, and destroy it once it’s done. This way you can have as many latent functions as you want running at the same time.

1 Like

Spawn an ‘event handler’. So you write a new BP that just runs your event and timeline ( or whatever it is ), which you can pass your parameters to.

When you want to run them independently, just start spawning them :slight_smile:


Call set up the event by timer and make it to any time that you wanted to set. and It will run events that you set earlier together.

1 Like

As I understand, the issue is there must be one function. Like you press a button several times, and it sets an individual timer for each key press. You can’t set the infinite number of timers by one function. But with a separate actor, you can:


“Set Timer by Event” (UKismetSystemLibrary::K2_SetTimerDelegate) won’t work if the previous timer still exists. “Set Timer by Function Name” won’t work either as it calls UKismetSystemLibrary::K2_SetTimerDelegate internally. The reason for this behaviour is this Line which looks for an existing TimerHandle to the same function. In case it finds an existing TimerHandle it updates that instead of setting a new timer.

While the method of spawning a new Actor for each timer certainly works, it may be better to create a small C++ FunctionLibrary that exposes a SetTimer function without this behaviour. That way you save the Actor-spawning and memory overhead.