Dynamic Selector and Failing ActionTask

[yoziva]

Hello,

I wonder why an ActionTask that has failed is not reevalutaed by its Dynamic Selector parent.

I have 2 tasks, children of a Dynamic Selector (check attachment) :
– An Attack” task that fails if the agent cannot see his target.
– A “Move” task that pathfind and move the agent closer to his target.

I would expect the following behavior :
– The “Attack” task Execute() method fails because the agent is too far. It gets reevaluated constantly.
– The “Move” task bring the agent closer.
– The agent is in range
– Because the Execute() method of the “Attack” task is reevaluated, this time it succeed.
– The “Attack” task Update() method is called until whatever.

Do we necesserly have to use ConditionTasks to make sure Tasks get reevaluated ?

Thanks.

Attachments:

You must be logged in to view attached files.

[Gavalakis]

Hello,

You would need to use ConditionTasks for conditions instead of ActionTasks, yes.
ActionTasks are not revaluated this way, because if the action was created in a way as to return Running, it would mean that both of these tasks would run in parallel, which is not desired when using a selector.
Is there any specific reason you don’t want to use a condition task?

Cheers!

Join us on Discord: https://discord.gg/97q2Rjh

[yoziva]

As I understand it, a ConditionTask should only execute a test. It shouldn’t modify the game state (readonly). The two tasks I need (“Attack” and “Move”) are modifying the game state.

In my “Attack” task, the Execute method is checking if the agent is in range of his target. If not in range, the task fails. If in range the agent start shooting and therefore it modifies the game state.

In a way the “Attack” could be split in two task sub tasks:

• A ConditionTask (“IsInRange”)
• An ActionTask (“Attack”)

It would work, but it makes the tree more complicated and more error prone:

• In my example there are only 2 nodes. But it’s easy to imagine that every time I will need to use a Dynamic Selector, I will need to have 2 nodes (condition+action) instead of one (action).
• Also, one cannot use the “Attack” task by itself. We need to be careful that the “Attack” node always comes after an “IsInRange” task.

Would it fundamentally break existing behaviors if the ActionNode::OnExecute method was calling ExecuteAction not only when the action is Resting or Running but also when the action has Failed? Could it be a setting of the Selector?

1 2 3 4 5 6 7 8 9 10 11

protected override Status OnExecute(Component agent, IBlackboard blackboard){   if (action == null) return Status.Failure;       if (status == Status.Resting || status == Status.Running || status == Status.Failure) return action.ExecuteAction(agent, blackboard);   return status; }

[Gavalakis]

Hello,

Yes. Idealy, conditions should not change the game state.
To me, it seems like you are seperating your tasks in a similar fashion to states, where for behaviour trees it most likely isn’t going to work nice.

Personaly, I would have split this into:
– HasTarget (condition)
– AttackTarget (action)

Where the AttackTarget, would include how the character moves up to that target to be able to attack correctly.
Alternatively, you could simply create a single action AttackTarget, that includes the move to target as above and checks if the character has a target. A more self-contained action task.

The change you are suggesting will unfortunately break existing behaviour indeed and will not work correctly in all scenarios, like for example under a Dynamic Sequencer, where instead of executing the action even in case of Failure, you would want it to execute it even in case of Success instead, since basicaly Sequencer works vice-versa of the Selector.

Let me know.
Thanks.

Join us on Discord: https://discord.gg/97q2Rjh

[Author]

Posts