This is a minimized version of BT that reproduces a bug I came across:
Expected: both WaitForever nodes run
Actual: only first WaitForever node runs
WaitForever is a very simple BP-based Task:
P.S. I’m using UE 4.6.
Thanks for reporting this bug. I disabled external overrides of execution order (loop decorator) in CL# 2388636.
If you need to update it on your end, please change UBTCompositeNode::SetChildOverride function to virtual and implement as empty for UBTComposite_SimpleParallel class.
So, instead of being broken in one way (second child doesn’t run at all) it is now broken in the other (first child doesn’t loop). Do you really think it is an improvement?
Worse, now it will silently ignore loop, forcing users to debug why this thing doesn’t work. And after debugging they will end up in your override and scratch their heads asking themself “err… So, how to workaround this?”. For example, my main task was supposed to be MoveTo, it doesn’t have any way to be continuous without loop decorator.
It’s indeed a bit unfortunate. If loops are not supported a user should not be able to place a decorator of this type on simple parallel’s children. We’ll have that addressed.
However, if I understand you correctly, you should be able to work around this issue by changing your BT structure. I don’t know the specific set up you have, but usually moving the loop decorator (or other like that) up the tree gives similar (if not identical) results. If need be add an extra composite node to contain the loop.
To be honest I was never a fan of our SimpleParallel node, and I avoid it whenever possible, and you can go really far by doing the “background behavior” with services.