From what I have seen, in the Behavior Graph there is no way of creating a List of a specific Type beside the presets on the blackboard.
E.g. Any ScriptableObject. Workaround would be to reference a Class that has that custom List inside.
Am I missing something?
2 Likes
Hi @NixonAroboX !
Your understanding is correct - weāre currently only supporting basic types for list variables created through the Blackboard menu. We would definitely like to extend the selection of types that can be used for lists (including custom types as well), but havenāt gotten there yet due to other priorities. Hopefully soon! 
1 Like
I was searching for the same functionality when I found this. The behavior graph package is so close, but just a few missing features like this are really limiting.
Itās nothing thatās too bad, just create a bootstrapper class where you store your custom lists and arrays. You just reference the bootstrapper in the blackboard and youāre fine
I am using behavior graph for our current production title
1 Like
Thanks for the reply. Iām using the paid asset āBehavior Designerā, and I was just checking out the new behavior graph package. A few things like this, not being able to assign default values, and not having standard āpublicā variables that are only visible in the inspector are disadvantages that will probably keep me from switching over.
That being said the editor performance and UI are much better, and the future for this package could be great. If I wasnāt already invested in a different solution Iām sure I could use the behavior graph package with only a few tweaks and workarounds.
I respect that.
Def. keep your eyes open about updates on behavior graph, the team is working very hard from what I can tell. If it is not for you now, it may be after a couple of updates =)!
1 Like
Hey @wyattwilson, thank you for the feedback!
Iād like to attempt to answer some of it:
not being able to assign default values
What do you mean by that? Is it in nodes or Blackboard? Because you can assign default values in both.
- Assigning a value in a blackboard variable for the graphās blackboard will show that value as default in the inspector.
- In a node class you can assign a default value like the following:
[SerializeReference] public BlackboardVariable Speed = new BlackboardVariable(1.0f);
Please note that if the node was already created it wonāt reset to the new value and youāll need to re-add it to the graph or set it manually.
not having standard āpublicā variables that are only visible in the inspector
I assume you mean non BlackboardVariable fields in nodes? Iām hoping to tackle that one early Q1
Can I ask you to provide me with more blockers and quality of life issues that stop you from moving to this package? Whatās your wishlist?
Hi @LauraRantonen ,
First of all, thank you for clarifying about the default blackboardvariable values for nodes. I didnāt see this mentioned in the documentation, but I like the implementation.
Also to clarify, yes, I was referring to non-blackboard variable fields in nodes. Having all variables in the node description gets very verbose very fast, and not all fields have equal importance or frequency of use, so I look forward to having this option, especially for more complex actions.
On a related node, Iāve noticed a formatting issue where the āstoryā doesnāt seem to format blackboard variables properly when using multiple lines via ā\nā. The text does break into a newline, but then when reaching a blackboard variable the text seems to center vertically. (see image) Maybe this is just using the āstoryā in an unintended way however.
One of the issues Iāve encountered are how ticks work. I see that I can manually call the āTickā method for a behavior graph to update, but is there an intended way to stop the automatic call of āTickā every frame? My use case involves many enemy objects, and ones that are of lower importance and higher distance from the player donāt need to be called every frame. I suspect I may be able to prevent the automatic calling of āTickā by disabling the Behavior Agent component, but I havenāt tested this yet.
I am also curious what exactly occurs on a āTickā. Does the graph execute until it reaches a ārunningā status? Upon a nodeās āSuccessā does the next node call āOnStartā and āOnUpdateā that same tick (assuming that "OnStart returns Status.Success)?
I am also curious about the āStatus.waitingā behavior. I see that this is occurring while child nodes are being executed according to the documentation, but to me it is unclear exactly what that means. Is this only for use with flow nodes, for example a sequence node returning āStatus.iswaitingā while the children are being performed?
Now I may have some bad habits regarding how some nodes are intended to be used since I am coming from a different behavior tree implementation, but are aborts only called once in their sequence? The previous system I used had aborts implemented into its equivalent of āflowā nodes, and that abort would be evaluated every update, along with a hierarchical structure of higher priority sequences being able to āstealā the execution from lower priority ones. If this sounds convoluted, it is because it is (and it was poorly implemented), but I hope that the advantage of that system can be imagined. Let me give you the example of what I am currently using this system for:
My enemy npcs have a āstunnedā state when they have had their āpostureā bar fully depleted (similar to Sekiro). This overrides all other behaviors. So when the variable āisStunnedā is true the behavior tree should abort all behaviors being performed and jump to the āisStunnedā branch. How should this behavior be handled in the behavior graph? In the previous behavior tree system I was using, the previously mentioned āHierarchical priority abort structureā was a very inelegant solution that fit this exact scenario. I am just struggling to determine the intended method for implementing this type of behavior in the behavior graph. I do see potential solutions with custom flow nodes, but hopefully there is an integrated solution.
All of that being said, I decided to start migrating towards the new behavior graph due to its better editor performance and ui. There is a lot that I am impressed by. I really hope that it is widely used because it seems like a significant tool for the vanilla Unity experience. I just hope that the documentation is updated to be as pedantic as I am, and that the examples in the demos are made significantly more complex to show how more advanced behaviors are intended to be implemented.
Thanks for replying and showing interest in my feedback. I am very excited about the potential of this package.
1 Like
Hello @wyattwilson ,
Thank you very much for taking the time to share your feedback 
There is a lot to cover, so I might miss a few bits, donāt hesitate to ask for more details!
I think there is a bit of confusion here. We indeed donāt support direct āconstantā that would allow to display non-BlackboardVariable [SerializeField] type to a node. However it is already possible have a serialized BlackboardVariable not specify the node story ā it will in that case be display in the node inspector:
Looks like something we didnāt expected 
It is true that the node story support rich-text (which is neat to use things like bold and italic). But you are probably the first user trying to use it to multiline. This is not something we want to support as far as I know, as the goal is to let user create to short node instruction that should be short and easy to read. Actually we even have plan to limit the maximum limit of character that a node story can display (or at least limiting the amount of character user can set when creating a new node).
Like you mentionned, you can prevent a graph from running by disabling the Behavior(Graph)Agent component.
Aditionnally, we are working on improving the general lifecycle of BehaviorGraphAgent, and one of the area we would like to improve is the ability to specify the Update method of agents. This way you will be able to choose when they should tick, but also could start implementing Level Of Details mechanism for your BehaviorAgents.
You guessed right, when Tick is called, the graph is going to:
- Look if there are nodes to run
- If there are, start running them and their child until they all succeed or until one returns
Failure/Running/Waiting/ā¦ (ofc the actual flow mechanism can be complex as some nodes can run in parallel - sequentially)
The Waiting status can be use when a node wait for an external system. It usually means that the node started it and is now either going to:
- run forever (or until aborted)
- or is waiting for the system to finish before Awaking itself to then continue execution
A good example of node waiting is the Load Scene. It uses SceneManager to create an async request and wait for completion before resuming the node.
Iām not sure to understand your question. In Behavior, modifiers such as Abort, Restart or even Repeat are always going to affect their child (and underlyings).
This sounds like the priority system that Behavior Tree usually implements. We donāt have that ability currently in Behavior but we discussed some of the implication in this thread in case that might be of interest.
That sounds very interesting, I cannot really provide specific guidance as there might be more to consider, but something I usually recommend is to make complex behavior by using an FSM-BT hybrid approach. BT used to evaluate the state of your agent and FSM part to implement state and reaction.
Sounds like you already had a look at the Behavior Demo. Would you have suggestion of what kind of complex scenario you would like to see being covered?
Thanks again for taking the time to provide with such in-depth feedback 
1 Like