So, last night I had made a lot of progress and was setting up the way some of logic should work rather than the testing/hacking I had done earlier in this project. In this project, I had made it so that these arrows orient towards a certain target. When I finally set up everything clean and in order a few days later the arrows refused to work. As best as I could tell the “SetWorldRotation” simply would not set the world rotation on its objects, no matter how many different ways I got my target actors, etc. I added print strings to test it being fired (it was), but no luck. I was going crazy while half chalking it up to being sleepy. What confused me was that the logic was the same as when I was doing the testing/hacking stuff together phase, how did this break? I just remembered very briefly that when I was in that early stage, it only worked when I fired it after a delay. Of course, spawning them and then adding a delay to the logic and it works just fine now (.2 is too short but .5 seems to work just fine). There is literally nothing here based on time, it shouldn’t be waiting for any condition really for it to “work”.
Can someone explain to me why this happens? Is it a matter of newly spawned actors need a tick before they can be communicated to? Is the system trying to catch up briefly? Is there a better way to make them “wake up” without a delay?
My best bet would be that for whatever reason the order of execution was messed up and something that your arrows depend on is now firing after the arrows. Without you showing the blueprint no one will be able to tell you any more I’m afraid…
Ive run into a similar problem. I think that the problems i encountered on my end had to do with changing variable names which somehow causes them to return null values.
My code worked fine after i restarted my client/hit the ‘refresh all nodes’ button a few times.
Thanks for the reply. I really don’t see how but all the same I’ll post the entirety of the enemy_bp that the arrow belongs to. The arrow isn’t spawned, its a component in the blueprint itself. I moved the activation of the custom event to within the same blueprint (where the issue still occurs) for clarity.
