Download

Calling the same event twice causes the first execution to terminate - How to deal with this?

Look at this example: Repeated Event Example posted by anonymous | blueprintUE | PasteBin For Unreal Engine 4

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.

Am I missing something here or is that about it?

Thanks,
Chumble

Why dont you populate your HUD data from the HUD class instead. You can bind widgets to data in your pawn/controller using UMG.

you should read the description of delay

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.

Interesting read… Reminiscent of other Blueprint ‘gotchas’ you don’t see detailed in every guide / tutorial, but you definitely run into:

#1.
Similar to the case above: An instanced actor affects something that isn’t instanced, which in turn affects something that is… For example local-multiplayer split-screen with multiple player-controllers affecting Gamemode states, which in-turn impacts on instanced Pawns etc.

#2.
Spawning an actor that goes through a similar call stack to that above, but ends up spawning another instance of the same actor-class later on, thus creating an infinite loop etc… Or code that loops back on itself at some point (rogue logic branch etc), and then exceeds the maximum number of permitted BP steps etc.

#3.
Different start-up orders than expected in Packaged games versus Editor/PIE.

#4.
Finding something hasn’t been initialized due to an unexpected dependency order, different from predicted / assumed. So similar to the above example, but reliably reproduced (often accounts for lots Blueprint-accessed-none errors in the logs at start-up)… Begin Play Example

#5. Actor Spawning sync-issues / inconsistencies / race-conditions: Initialization / Timing example