Actor Variable Pointer Becomes Null

My actor is always Null when spawning an emitter. The emitter is supposed to spawn at the location of the actor, but it is always set as null.

It is going through a for each loop and being set to a different actor at the beginning of each loop.

Along the way, other nodes use the actor variable successfully, but always, when it gets to the Emitter node it is read as null. It is being unset after the loop is completed.

I have tried adding a cast to node to act as a sort of ‘signal boost,’ but to no avail.

[Forum Post Topic][2]

Edit: Okay so it was being unset after the loop had completed. I removed it and it started working again. Weird because I had tried adding a delay of 0.2 seconds to after it was completed. It was either too short of a delay, or there is a bug with For Each Loops executing the completed tasks before finishing the loop.

Maybe because it died and got deleted? Or the delay is allowing it to loop past and the actor has changed by the time the delay completes. Delays do not stop execution, it basically sets a timer and calls what comes after it when the timer elapses.

We could try to figure that out but the easiest way is around it: just save the info you need from the actor and use that after the delay. In this case, set a vector to the location of the victim when you call ReceiveDamage then use the vector in the spawn-emitter.

But if you’re assuming the delay will stop execution this may not work out anyway. If so, be more specific. Is this like a hot-potato game or something? Your loop is going round-robin?

Give this a shot and see what happens

But the loop does complete. That’s why I showed that example loop.

The Delay does not pause the loop, it zips right through the items in under a millisecond and the Delayed code is only called once after the period specified. Try the example it if you haven’t. Look at how the print-strings come out. This isn’t a bug. It’s just that you can’t do what you want to do with this method.

What you want to do is set a looping timer and go through the items each time it gets triggered. That will do what you need.

Yeah, that’s exactly what is happening. The actor pointer is de-referenced before the loop is complete.

At first I just had everything connected to the actor pointer coming from the for each loop itself (from an array of actors) and was having that error. Then I added a variable to hold the pointer, but made the mistake of trying to clear it when the loop was completed. I removed where I had set it to none after it had completed and it began working finally.

I totally still consider this a bug though. I think Epic should fix this. The loop shouldn’t de-reference the actor or run the next loop until the current loop is complete.

Except that you used a for loop. My problem was not that the For Each Loop (with an array of three actors connected to it) was completing before the end of the loop, it was that the pointer to the actor was being de-referenced before that specific loop instance was completed. With an array of three items It would de-reference the actor before it was finished with the loop all three times.

That’s why I still believe that it is definitely a glitch.

I never put a delay in any of my loops. That’s not the problem.

I only mentioned putting a delay in the code after it was completed and before de-referencing my custom actor pointer. It didn’t work, so I removed the delay.

Removing the unset actor pointer after the completion of the loop and putting it before the entire loop instead worked.

The type of loop doesn’t matter. Delay will not behave the way you want it to because that’s not how it is designed. Put the print-strings in your loop and see.

If the Delay kept the loop from continuing then you would lock up the entire game (I’m assuming this logic gets called from the main thread).

There is indeed a delay in the image you posted. Good luck I’m out.

You’re right. I’m sorry about that. I didn’t notice it somehow because it was connected to a variable. But it still shouldn’t be de-refencing just because of a delay…

I thought you were talking about the delay I put after the loop was completed.