Custom tick and subtree reevaluation in Behavior Designer Pro

[Rejected Games]

Hello,

We are using a custom ticker which updates the behavior tree less frequently than the default "Every Frame" update. When the tree is executed through this custom tick, the tree does not reevaluate.

Additionally, when we add a Subtree Reference node to the main tree, it seems impossible to use the custom tick. We receive a warning that the tree is not being activated.

Because of this, we are unsure how reevaluation is supposed to work when using a custom tick together with subtree references.

Could you clarify the correct approach for triggering reevaluation in this setup?

 

[Justin]

When you say reevaluate, do you mean conditional aborts reevaluation or reevaluating the subtree reference?

Based on your screenshot you are not using a custom tick setting.

 

[Rejected Games]

Hello,

Thank you for the reply.

To clarify, I mean re-traversing the entire subtree from the beginning, not conditional abort reevaluation.

We recently migrated from the previous version of Behavior Designer to Behavior Designer Pro, and in the previous version the tree would start again from the root when ticked.

Right now the behavior looks different. The subtree executes once and then stops doing anything, even though we are using manual ticking and explicitly calling the Tick() API.

I also realized that I accidentally attached a screenshot showing the component with the wrong settings. I will send another screenshot with the correct configuration.

So the core question is:
How should we trigger a full traversal of the subtree from the start when using manual ticking in Behavior Designer Pro?

Additionally, we have a question about OnReceivedEvent nodes. Should branches starting with OnReceivedEvent be placed in the main tree, or can they also exist inside a subtree and behave the same way there? In other words, are they executed and listened for events the same way when placed inside a subtree?

Thank you for your help.

 

[Justin]

I don't see a subtree attached to your component. And when you say it executes once, do you mean the entire tree executes and then stops over multiple frames or it only executed one frame?

Additionally, we have a question about OnReceivedEvent nodes. Should branches starting with OnReceivedEvent be placed in the main tree, or can they also exist inside a subtree and behave the same way there? In other words, are they executed and listened for events the same way when placed inside a subtree?

Event nodes do not get injected into the main tree from subtrees. This has been added in the next feature update of Behavior Designer Pro though. The code is done I'm just waiting on Unity's recertification since there are EULA changes with this release.

 

[Rejected Games]

Thanks for the reply.

Let me clarify the scenarios we are encountering.

Scenario 1
We load a subtree directly into the Behavior Tree component property (as the main tree). In this setup we are using manual ticking and calling the Tick() API. However, the tree does not tick at all and we do not receive any warning about the tree needing to be activated.

Scenario 2
Instead of assigning the subtree in the component property, we create a main tree and place the same subtree inside it using a Subtree Reference node. In this case the tree also does not tick, but we do receive a warning that the tree needs to be activated.

Our goal is to have the tree tick at a fixed interval (0.22f) using manual ticking.

At the moment we cannot determine the correct setup that allows the tree (or subtree) to tick properly with this interval.

Could you clarify what the correct configuration should be for this case?

 

[Justin]

You can do either. I just tried the first with this test scene by ticking the tree within FixedUpdate and a manual tick mode. The tree executed correct across multiple frames.

 

[Rejected Games]

Hello,

We managed to resolve the custom ticking issue, thank you for your guidance.

We have run into another question regarding setting a GameObject to null.

In our behavior tree we were setting the mob target to null in certain situations using the Set GameObject node. This caused several issues. After investigating further we discovered that in Behavior Designer Pro the value cannot be null and it falls back to the tree owner instead.

We worked around this by creating a custom task that explicitly sets the value to null and this seems to be working correctly.

However we are curious about this change. In the previous version there was a boolean option to allow null values.

Why was this behavior changed in the Pro version?

Also is our current approach using a custom task to assign null safe or could it lead to any unintended issues internally?

We are asking mainly out of curiosity and to make sure we are not introducing hidden problems.

Thanks

 

[Justin]

Glad you got it.

You bring up a good point with setting the null GameObject. There's no reason against it, just an oversight. I'll include the option again in the next update.