So I’m making a decorator that does not have conditional logic, so I dont need the observer abort rules really. OnBecomeRelevant and OnCeaseReleveant, should be called when the task I’m attached too becomes active? It seems without the abort rule set, the three doesn’t know that it needs to update that decorator. Is this the desired behavior? It seems like an unneeded constraint.
Hey Troy,
Have you tried setting bNotifyBecomeRelevant to true in your custom decorator class?
Cheers,
–mieszko
1 Like
This flag is only for gating virtual call 
Become/CeaseRelevant events are used only with aborting decorators, because it doesn’t have to match “branch is active” rule. E.g. decorators in “abort lower priority” mode are relevant only when their branch is not executing, but lower priority ones are.
Check OnNodeActivation and OnNodeDeactivation (with proper bNotify gate flags). They fire with search flow, not branch execution, but maybe this will be enough. If this approach gives too many false positives (search flow enters and leaves branch without executing anything) you’ll probably need to use service.
Yeah, I had the flags set. Thanks for the info Lukaz, it seemed like something with execution. I’d use a service, but I can only put them on composite nodes. So that isn’t going to help me much.
Ok thanks.
Does tick have the same rules?
Unfortunately it does. Only actively observing decorators will get one.
You can make a decorator locked in “abort self” (like TimeLimit) mode with always passing condition as a workaround before 4.12 adds services on tasks. It will be active with the branch and receive all updates you want.
So, something like this:
FlowAbortMode = EBTFlowAbortMode::Self;
And this will make sure become and cease are always called? If true, this is a fine workaround until 4.12.
Pretty much. You can clear both bAllowAbortLowerPri and bAllowAbortNone flags to prevent changing this mode from editor too.