Is it possible to set up multiple SetTimerbyFunctionName's for the same Function?

To restate the question in a more thorough manner, my goal is to be able to run multiple SetTimerbyFunctionName’s at the same time, but with different delays, so that multiple instances of the same function are “queued” up.

My experience with this thus far is that it’s not possible because calling SetTimerbyFunctionName on the same function appears to result in the newest call overwriting the previous one. I understand that there is a Struct called a TimerHandle that can be used to reference the Timer that is returned when it’s set but I don’t know if there is way to avoid implicitly referencing it, as it appears to be doing.

Additionally, I’ve run up against a problem where these functions won’t know which Struct to use for their particular call because parameters can’t be passed into the TimerFunction calls. I thought to get around this by storing the next Struct of Data into a variable that the TimedFunction would check, but I’ve realized while typing this post that the value is just being quickly overwritten before the TimedFunction has had time to figure.

This leads me even further to the belief that this is an improper use-case for SetTimerbyFunctionNames and I might be better off setting up a method that manually counts time/frames itself but I figure it still worth checking here to see if I’m misusing the node or if there is a different one that is a better for my use-case.

Below is a screen snippet of how I have the nodes configured. For a fuller context of what I’m trying to do with this code, I am storing an array of Hitbox data into Structs. This array is then iterated through, setting the Hitbox Data as it’s own variable and the function responsible for drawing each of these Hitboxes is called with a timer:

TLDR:
I want to loop through an array, calling a SetTimerbyFunctionName on each of its elements but am facing two problems.

  1. The timer seems to reset with each call, effectively overwriting the previous call.
  2. If I’m not able to pass parameters into the Timed Function call, how can I make each of the Function Calls know which element they are meant to operate on.

Is there a way to resolve these problems with SetTimerbyFunctionName?
Is there a different node or set of nodes for this use-case?
Would I be better off coming up with a custom approach to tracking time and kicking off delayed function calls that way?

Perhaps it would work to directly call a custom event with a float input and a delay node at the beginning instead.

what if you do this:

create an actor with the function you want to use only. how many instances you plan to use at same time?

just spwan the actors you think are the top parallel running timers and store in an array then each time you want to use the function you take an actor, send the data needed for the function and if you want some callback you can even use some dispatcher in the actor and bind into the blueprint you want to use it. Is not easy to explain all the proccess but maybe you get the idea. even you can move the actors in use to another array and when they finish the task come back to the ‘ready to go’ array again.

Delays were something I was initially avoiding, just because I’ve seen a number of forum post/videos suggesting this wasn’t appropriate for handling concurrent function calls. I just took a crack at implementing this as shown in the screenshot below (For simplicities sake here, I’m just hard-cording the delay to 2 seconds).

The Hitbox array has two elements inserted during the BeginPlay event so I would expect this to generate two messages stating “Iteration: # of the Hitbox Array” where # is either 0 or 1 and then two messages stating “GenerateHitbox Called”. But in actuality, only one “GenerateHitbox Called” is printed, so I believe there is an issue with concurrency being stifled by the Delay node.

Hmm, I think understand this approach. I don’t have a hard number as to how many Hitbox could be stored into the array. This is for a Traditional 2D fighter and my thought is to handle it on a per “move” basis. So I imagine the upper end could see something like a dozen or so hitboxes for fast-hitting Multi-Attack moves.

I was already using Actors to represent the Hitboxes, but wasn’t including the logic for setting up their Transform inside them directly since spawning an Actor required a Transform anyway, but that actually seems like a good, natural way to configure these to operate concurrently.

I’ll take a crack at this approach :+1:

1 Like