The “Timeout” ConditionTask is better only to only be used in the context of FSMs.
If you are referring to BehaviourTrees, it would be far better to use the “Timeout” Decorator node instead.
Are you indeed referring to using the “Timeout” ConditionTask in BehaviourTrees?
Thank you for your explanation. I indeed was referring to using the timeout condition task in BT. Didn’t know it was designed for FSM. That makes sense.
What we need is an “inverted-timeout” decorator, which returns failure and blocks its child connection until a timeout. We have been achieving this by using the combination of conditional + timeout. (or wait until + timeout)
Thanks for the follow up. Indeed there are numerous results that can be achieved by combining different decorators.
Another “time” related decorator that you can look into, is the “Filter” decorator, set to work as a “CoolDown”, which might or might not be what you want in your particular case of course.
Thanks Gavalakis. CoolDown is not exactly what we need since we need the Countdown to start immediately, not after first execution. We have written our own decorator to handle this situation.
Thank you!
Author
Posts
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic.
Login
Register
By registering on this website you agree to our Privacy Policy.