I have encountered an issue with YieldResult in ConditionTask. The problem arises when the condition task uses blackboard variables as arguments (or uses a blackboard variable for the agent) It seems the YieldResult mechanism does not take into account any changes to the input arguments of the node. I.e. it does not invalidate the result when the input arguments no longer match.
Here is an example: (see attached files)
The behavior tree uses one variable named “Collider”. The scene has 2 cubes with box colliders.
The BT first sets Collider to Cube (1), then performs “Check Mouse Click” for blackboard variable “Collider”.
If “Collider” was clicked, the value of “Collider” will change to Cube (2).
The next branch again performs “Check Mouse Click” for “Collider”.
Observed behavior:
The second “Check Mouse Click” for the “Collider” variable succeeds even though I did not click on Cube (2).
Desired behavior:
The second “Check Mouse Click” for the “Collider” variable should fail. The value set by YieldResult should be discarded because the agent changed.
What do you suggest? Is there any way to invalidate the YieldResult value when the agent changes? What about other input arguments?
I changed the code of CheckMouseClick2D.cs to work around the issue: (NOTE: To fix the issue above, you’ll need to change CheckMouseClick instead of CheckMouseClick2D, since that is what I used in my example scene)
I’m not sure yet if this approach will create other issues, but so far it seems to do the trick.
However, this does not solve the general issue with YieldResult, so I would still like to know your opinion on this matter.
Thanks,
Tim
Sorry but I somehow thought I had replied :-/
Indeed, the problem with original implementation and YieldReturn result in general, is that it is made so that the result condition (true/false) is held up and returned for one frame. As such, if within the same frame the agent is changed, it is not really taken into account.
Your solution of caching the agent is interesting and is possibly something that can be implemented in the base ConditionTask class itself so that it works for all inherited conditions.
I will take a look at this possibility once able.
Thank you!
Join us on Discord: https://discord.gg/97q2Rjh
Author
Posts
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.
Login
Register
By registering on this website you agree to our Privacy Policy.