Blueprint function local var never de-reference

Development Programming & Scripting Blueprint
, , ,
1

When you use a function’s local var to store or set to none before you return trace result, it will lead to local var in function to never dereference actor properly where the trace will always return a hit, and result will always return even if you change trace location later on.

In the below example, open the project, and PIE. Hit T to spawn actor, hit LMB to start a trace and then store reference in level blueprint, and then use R to destroy referenced actor so it no longer exist in view(nor in editor outliner). But if you then hit LMB again, message will tell you that trace still hit the actor destroyed, if you then hit F to invoke even dispatcher, it will even confirm interface is implemented.and run the interface function of that supposedly destroyed actor.

In short:

  1. load project, play in editor

  2. T to spawn, LMB to trace, R to destroy

  3. LMB again and F to show bug.

Example project for reproduce the problem.
https://drive.google.com/file/d/0B-tFdrK3eZLYbFJueFBFQWstTmM/edit?usp=sharing

2

Add function BP screen cap here.

3

Hi PenguinTD,

Unfortunately the project does not upload properly, can you try to re-upload it so we can have a look? Thank you!

4

Hey PenguinTD,

I was able to reproduce your issue with a similar setup. It appears that when the trace fails at the Branch, the local variable does not return the default value correctly. If you hook up the “False” pin to the result node, it appears to work without a problem.

This is indeed a bug, a bug report will be filed. If with the pins connected you still see the issue, we may need to see the project as reported having issues with the upload.

Thanks!

5

Try this one.

6

it does solve the problem if I connect also Branch’s False pin into isValid node’s input pin, but it’s kinda weird. I then connect the False pin also to Assign None node, it also works this way and seems to me more logical. I uploaded the filed again to dropbox, hope it works this time.

Thanks for providing an answer, but the cached behavior is certainly weird, and hopefully fixed(resetting function instance?) in the future.