How would you recommend modifying the Filter decorator such that it would run once while still in the same active BT or sub-tree. A great example would be set the animator parameters ONCE in, let’s say, a Patrol BT where the agent is merely chasing the target transform(I’m thinking A* RichAI, for example). I get frustrated watching the active task ever so slowly switch from one to another. HashID’s speed it up a bit, but still, there should be no reason to get at the animator parameters if they haven’t changed.
We utilize the Filter decorator in situations with Run Once for some caching, role and capability attributes and the like and it is ideal in that regard but, if I’m not mistaken this decorator is initialized in OnAwake so it persists in its last state throughout the session.
Hmm. The way Behaviour SubTrees work now, this is not possible to do and would require some changes in the code more than just the Filter decorator itself, since for the Filter decorator code, there is no difference whether it lives in a root or sub tree. All SubTree nodes, are basically treated as being part of their parent tree. As such, the OnGraphStarted callback in nodes for example, is only called when the root tree starts.
With a few changes though, I think I can make it so that it only gets called when the actual graph of the node is started, and if that does not creates any other sort of problems, I could make the change permanent and included in the next version. If so, then the Filter decorator (as well as all other), will automatically work only in relation to their graph. I will have to check this possibility.
I really think though, that the Animator.GetFloat/Bool/Int etc methods with an ID are quite fast. Do you observe any performance hit in the profiler?
I appreciate you taking the time and a closer look at this topic. I could see from the structure it was not going to be one of these “oh, sure why not”. If what you were proposing would permit the Filter “Limit Number Of Times” to be relative only to the current activation of the BT or sub-tree and then reset when it is deactivated (say a switch from a Patrol to Combat tree) and then could filter again under the same parameters if re-activated, that would be splendid. The way I see it right you can use it only once in a game session which, BTW, we use to pause execution at the very beginning for caching references and other sorts of lengthy ho-ha.
Regarding the Animator, let me put it this way, you must put a Wait action before or after a task of condition node if you need to micro-Debug and make sure something is firing. You can watch an Action List of any Mecanim call as it leisurely make its’ way through the list, HashIds or not.
I wouldn’t fiddle with a change if we could safely get it to perform as in paragraph 1.