I had some questions/concerns about how decorators interact with selectors, specifically with the notion of bp-based decorators that can be ticked.
This largely builds off the discussion here:
How to achieve “Active” selector node functionality in UE4 Behavior Trees?
Here’s an example: say I have a decorator that wants to detect (every tick) whether some value has exceeded a threshold (say my “weapon heat”). The only way I can get the effect of testing this every tick is to place weapon-heat in the blackboard. Correct?
This is frustrating for several reasons:
- this might be the only decorator in the entire tree that cares about weapon-heat, so it seems wasteful to pollute the global blackboard with this value
- I need to create some OTHER mechanism to make sure that weapon-heat is properly fed into the blackboard with the frequency I need, which means that the weapon-heat-threshold decorator is no longer a self-contained piece of logic – I need to know that it won’t work without this OTHER service in place
- In other words, you haven’t avoided the need for ticking, you’ve merely obfuscated where that ticking takes place.
I think my high-level observation is: this aversion to ticking is strange, and I’d much prefer to allow some option to tick my bp-authored decorators and take responsibility for the perf implications. In the example above (and I suspect many examples) the freedom to tick significantly simplifies the tree.
tldr: a feature request, for the option to allow ticking of bp-authored decorators.
I am assuming, by the way, that all of this ONLY goes for bp-authored decorators. If I were to implement a “weapon-heat decorator” in c++ I could override the tick() function and request execution every tick. Correct?
Thanks!