Reposting a bit from my separate response to zoombapup’s question:
We don’t support multiple blackboards directly. However, there are ways you can use multiple blackboards.
First, we support blackboard inheritance. See my post here about “Parent” tab in the Details view. (I’ve also just made a note to add a specific section about blackboard asset inheritance to the blackboard documentation.)
Blackboard inheritance lets you use a base blackboard with common values for all AI while adding additional values to more specific AI in a hierarchical fashion. Then you’re still referring to a single blackboard based on the AI using the behavior tree in question. (Since the behavior tree will generally refer to specific key values, it makes sense that a specific behavior tree is tied to a specific blackboard.)
Conceptually, a blackboard stores all information needed by a specific behavior tree, so it shouldn’t need multiple ones.
Our support for “Run Behavior” nodes (which effectively run a subtree) does NOT allow you to use multiple blackboards. Each subtree is conceptually part of any tree that calls it, so they share the same blackboard. That means the blackboards must be compatible (anything you reference in a subtree must exist in the parent tree’s blackboard).
One way you could do this would be to have an AI Squad actor of some sort that would have its own behavior tree to decide what the squad is doing. That behavior tree would of course have its own blackboard, and it could also post data to specific “squad” information in the individual AI’s blackboard, which would then cause the AI’s actions to change appropriately (through its behavior tree). You can already post to or read keys from any blackboard in a behavior tree blueprint node. See this post about how to set and get values in a blackboard. You can use the “non-behavior tree” functions to set and get the values on any blackboard component (so you just need to access that component on the pawn from the squad to write to it.
You could obviously write your own helper functions as well to write to all squad members’ blackboards if necessary. Whatever solution you pursue, I’d be wary about having arbitrary numbers of trees hooked up. It ultimately may lead to a lot of confusion about where data is coming from or where it should be set. The solution above might be nice because the communication is one way (squad setting values into individual AI blackboards) and shouldn’t require reading from them at the squad level or writing to them at the individual level.
You can use the same general functions above to share a blackboard if you want. Or have the social object detect AI and write to their blackboards. (The exact best solution of course varies depending on exactly what you’re trying to do.)
I hope this helps. If you have specific reasons that you think we need direct support beyond the blueprint mechanisms, let us know.