So, I call “TestingSanity” once immediately with a “0”. It prints to the screen repeatedly.
After 5 seconds, I call “TestingSanity” again with a “1”. I can see from the output that the "0"s stop getting pushed to the screen and now "1"s are displayed instead.
I somehow have gone this long without realizing this behavior. I am in a scenario where I am checking to ensure the HUD exists before populating it with data and I am delaying until it’s ready. But while delaying, the event is called again with different data. The first iteration of the event is terminated and I only ever see the second.
I’m guessing I could do this in a function instead to prevent the termination but you can’t use delays in functions so waiting for a HUD to exist won’t work.
The only solution I can think of is to add the data to an array and have a single event repeatedly processing the array elements and adding them when the HUD exists. It seems like a sloppy and unnecessary solution.
Well, this requires adding children to a panel so I don’t think that will be useful.
“Perform a latent action with a delay (specified in seconds). Calling again while it is counting down will be ignored.”
That doesn’t really address the issue. I had assumed (apparently incorrectly) that calling an event that is already executing would create another thread to handle a second execution. I don’t think this has anything to do with the delay node other than it being the tool used to prolong the first execution however I imagine an event with a long series of calculations would have the same issue.
If you have any time delayed node along an event that loops back on itself and you need to call multiple times, consider spawning an actor to hold that instance of code for you. In your example, you are firing into the same instance and essentially stepping on the thread.
If the event is not delayed at any point (even if it’s jumping through miles of 3 dimensional arrays), as long as it definitely won’t loop infinitely, then no sweat.