Request for a "Time Limit" node

Nightkin

New member
Hello again, sorry for asking more questions...

In my behavior tree I have a need for a lot of nodes like "do an action and wait for its effect to complete, or X seconds, whichever comes first". For now I do it like this :

2021-09-06_175103.jpg

The blue "wait until door is open" node essentially keeps Running until the door is effectively open. But this may take forever, especially if there is something in the way because my doors are physical, so in parallel there is a timer that returns failure after 2 seconds. Whichever stops Running first stops the whole sub-tree thanks for the Parallel Complete node. Don't mind the blue color, I just color any node that references another one so I remember who needs what.

This solution works but I find it a bit cumbersome and I would rather do it like this :

2021-09-06_175120.jpg

This decorator is supposed to return Running while the child is Running, or the status of the child if it's not, or Success or Failure (specified in the node) if the timer expires first.

It is cleaner and more intuitive but this "Time Limit" task does not work because it does not execute while the child task is running. I understand that this is probably by design so I thought of starting a coroutine in the OnStart () function to let the timer run in parallel but I don't know how to interrupt the child task when it expires. I've looked into the code of the other decorator tasks but that didn't help me much, all of them run only once their child has returned a result.

How could I write such a decorator task ?

Thanks !

PS : On a side note, I read somewhere that conditional tasks should never return Running because they're not doing anything, they're just checking data. I agree but on the other hand, I don't see the need for distinguishing actions and conditions since they both return a result. To me there should be only action nodes. Moreover, this particular task waits for something to happen, so although it's not doing anything on its own, it still needs to wait and not return a result right away.
 
Have you seen the cooldown node within the latest update? This node functions very similar to what you are going for, here's the original request for it:


PS : On a side note, I read somewhere that conditional tasks should never return Running because they're not doing anything, they're just checking data. I agree but on the other hand, I don't see the need for distinguishing actions and conditions since they both return a result. To me there should be only action nodes. Moreover, this particular task waits for something to happen, so although it's not doing anything on its own, it still needs to wait and not return a result right away.
Conditional tasks are a bit different in that they work with conditional aborts and action tasks do not. With that said, there isn't anything within Behavior Designer that prevents you from changing the game state within a conditional task so if it works for your situation then I would do that.
 
Thank you for your answer. Yes I looked at the cooldown timer decorator before writing this post, it seemed to be closest to what I wanted but what I want to do is different. From what I understand, the cooldown timer waits for the child task to complete then stays Running for some time before returning its own result, while what I want to do is the opposite : I want the time limit task to interrupt its child task if it is taking too much time, or to return the child task's status if it is fast enough.

But after giving it some more thought, I don't think this hypothetical "time limit" decorator task would solve all my problems after all because the "parallel complete" task already does, and there are some cases where I must have more than one "wait for XXX to happen" child tasks with maybe more than one "wait for YYY seconds" and stop waiting as soon as one of them stops being in the Running state. So what I did was much simpler, I made my own WaitCustom task that is exactly like Wait, but that returns a custom status instead of only Success, just to simplify the tree a tad bit by removing the need for a "return failure" decorator above the Wait task. It's nothing but it makes the tree a bit more readable especially given how many copies of this "parallel complete" sub-tree I will need.

It would be great to have this kind of decorator though for the simpler cases of "wait for XXX to happen but don't wait for more than YYY seconds" which are often needed.
 
Top