NodeCanvas Forums › Support › SendEvent in subtree
I’m new to nodeCanvas, but I think I’ve run into what I think might be a bug with event sending in subtrees. I moved a subset of a working BT into a subtree and found that my events stopped triggering. Upon investigating further I found that “SendEvent” isn’t working when called from my ActionTask, but sending the same event through “agent.GetComponent<BehaviourTreeOwner>().SendEvent” in that same class works. Here’s a simple example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
public class TestTask : ActionTask{ protected override void OnExecute(){ SendEvent("TestEvent"); EndAction(true); } } public class TestTask2 : ActionTask{ protected override void OnExecute() { agent.GetComponent<BehaviourTreeOwner>().SendEvent("TestEvent"); EndAction(true); } } |
In the above classes, TestTask will trigger an event in my main BT assigned to the BehaviourTreeOwner, but if I put the same task in a subtree under the main BT it will run but will not trigger an event. TestTask2 works in both cases. I’ve also attached screenshots that illustrate what is happening in the subtree. Notice that the first screenshot that the event condition on the left hasn’t been triggered (yet TestTask has executed).
Is this the expected behavior or have I run into a bug? I’m using Unity 2017.4.2f2 and the latest version of nodeCanvas from the asset store.
Also, I did some debugging and determined when calling “SendEvent”, Graph.SendEvent returns immediately as isRunning is false. When I call “agent.GetComponent<BehaviourTreeOwner>().SendEvent()”, the GraphOwner.SendEvent method calls graph.SendEvent and the same isRunning check now returns true and the event sends. Do I need to do something to set my graph ‘running’ in the subtree or set the graph reference in the subtree somehow?
Hello there and welcome.
This is indeed a bug. It is actually a by-product bug of a bigger issue in how SubTrees are handled and which is meant to be fixed for the next version. The problem is that BehaviourTree SubTrees, (in contrary to all other type of nested graphs), are not handled in the same way for (negligible) performance reasons, but that inconsistency can be the source of bugs like this. As such, I aim in the next version for SubTrees to be handled in the same manner and thus have such (as this) bugs resolved altogether.
If your current workaround does not work for your until the next version update, I can rush up the fix and send it to you if you want.
Just let me know if so and thank you for the bug report!
Join us on Discord: https://discord.gg/97q2Rjh
So far the workaround has been working fine, so for now I’m in no hurry for the fix. Thanks for confirming the bug.
I’ve run into a few other minor issues that I’ll mention here too in case you aren’t aware. They aren’t significant enough to stop me from using it, but they are a bit annoying.
Btw, I’m loving nodeCanvas. I’ve only been using it for a few days and already I can’t imagine working on another project without it.
Hello again and very sorry for the late reply!
Please let me address your points:
– I was able to reproduce this, It is basically a GUI issue related to the text field remaining in “focus” even if you deselect the node. I will have to fix this of course 🙂
– Generally speaking, predefined variables are certainly better and more.. “reliable” to work with thus I would suggest to use those whenever possible. I have many times thought of deprecating dynamic variables, but have not yet done so only for backwards compatibility reasons. With that said though, I tried replicating your issue but wasn’t able to do so. If you come by it again and you can reproduce it somehow, please let me know!
– Indeed, automatic re-ordering of nodes is intended behavior, based on their position from left to right in relation to their parent. Verticality should not be taken into any account, but please note that the position of the nodes is based around their “center” (not their left for example). Something that “might” be confusing since the horizontal size of the nodes can change (to show information), and thus when it happens, so does the node’s center. Could it be what happened to you as well by any chance?
Thanks a lot for your positive feedback! I really appreciate it!
Join us on Discord: https://discord.gg/97q2Rjh
Thanks for getting back to me. I’ll let you know if come across the dynamic variable issue again and a method to reproduce it, although I expect I’ll be sticking with predefined going forward.
Regarding the re-ordering, I tried to reproduce an example with the connection order not reflecting the canvas node order after moving the nodes and I wasn’t able to do so. However I did notice that the connection order is retained until one of the children is moved. That is, if I intentionally connect/reconnect them out of order they will stay as such until I move an out-of-order node, its siblings, or its parent.
So, I think what happened was that I either changed or added the connections between parent/child nodes after positioning the child nodes (at which point the connection order didn’t reflect the physical node order on the canvas). I likely had it working like this, then later came back to clean up the canvas layout and unexpectedly triggered the connection order change when I moved a node. That or I changed a node such that it became wider and the center moved as you suggested.
In either case I don’t thing there is anything wrong with the current behavior. Once I realized how the re-ordering worked I found it saves me a fair bit of time. However, it might be good to mention how the automatic re-ordering works somewhere in the documentation.
Thank you for the follow up and detailed post.
I will do indeed update the documentation to make more clear how auto re-ordering works.
Having said that, due to another post, I realized and just found a bug that was happening and which I think might be exactly what happened to you as well!
Please take a look at this post and let me know:
[LINK]
Thanks!
Join us on Discord: https://discord.gg/97q2Rjh
Yeah, the behavior described in the linked post is exactly what I experienced, and the fix/change you implemented is more intuitive than the current behavior. Thanks 🙂
Great! I am glad that this was indeed the culprit 🙂
Thanks for letting me know and if you would like, I can of course send you the fix as well.
If so, just drop me an email to support_AT_paradoxnotion.com as well!
Join us on Discord: https://discord.gg/97q2Rjh