I have a BFL with a function for determining valid shooting Transform from actor A at actor B. It calls line trace and does some angle-of-visibility restriction. There are 2 return nodes, the outputs are (1) a success boolean (2) the transform, which is a newly created zero transform for the failure case.
The calling actor is exhibiting race-condition type of behavior based on adding a lot of printstring debug logging nodes.
a) Calling actor calls BFL function.
b) function returns yes + good transform.
c) sometimes the BFL prints out again, very unexpectedly, before
d) the calling actor prints the result from BFL function.
Problematic step (c) sometimes happens and (d) shows a zero transform even though the boolean result was apparently true, because (d) only happens after a branch testing the returned bool from the BLF function.
Problematic step (c) sometimes doesn’t happen and then (d) shows a good transform.
Why on earth is the BFL library function being re-run or called again somehow?!?!?!?!
Blueprints cannot race, because they must run on the main thread.
If there are functions that are invoked more than once, then that’s because your game logic is wired to invoke it more than once. This may be because of some bug in your code, or it may be because you’re testing with a networking setup where there’s both a client version and a server version of the actor.
The blueprint debugger has breakpoints. You can select a node and press F9 to set a breakpoint. Set a breakpoint, and see where it’s being called from. You may want to add in a temporary switch node that switches on the output, and prints an additional string if the output value is “bad,” and put a breakpoint there, so that you can break only on the case where the bad output happens.
Thanks for your thoughts!! Thank you for explaining the no-racing.
The node in question is only 1nce in the graph and the things around it only happen 1nce. I suspect empirically there is more to the full story/understanding, which trips me up. I am learning. Also I have heard and sometimes seen that trying to use the debugger with BFL’s (sorta like with behaviour trees too) to be randomly not working. Also breakpoints really aren’t the ideal way to debug something that is related to something like a tick firing, sometimes printf log debugging is easier in my experience.
Anyhoooo: What I think finally fixed it for me was to change the utility function from “pure” to nonpure. The specification for how & when a pure node is evaluated, and how the outputs are/not “cached”, is unclear to me, and when I try to search about that subject I find posts from folks saying things like the behaviour actually seems to have changed among engine verisons. (I cannot find that in my browser history right now unfortunately.) (Overall I really love blueprints, I just wish things were somehow more clear or super well documented & tested.)
Also I have heard and sometimes seen that trying to use the debugger with BFL’s (sorta like with behaviour trees too) to be randomly not working. Also breakpoints really aren’t the ideal way to debug something that is related to something like a tick firing, sometimes printf log debugging is easier in my experience.