Replies: 2 comments
-
Actually, this could be simulated by having the Node Entity have a ReferenceDataComponent, which has an Entity field. The Authoring which injects the Reference Node into the ReferenceDataComponent's Entity field. The Entity relationship would thus be
Where the Node Entity operates on the ActualData Entity, which itself can be swapped with different or the same Entity. Sorry for the confusion, but this workaround should simulate this feature |
Beta Was this translation helpful? Give feedback.
0 replies
-
It seems like a
And there will be a tree scoped variant, ScopeComponentVariant, in next version. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While the Virtual Node maps a single Node to a collection of Nodes in a BT, this proposed Reference Node maps different Nodes in a BT to a single Node, so that all operations on any of those Nodes take effect on the referenced Node. This would serve a specific use case where a Node
2 is especially relevant if the feature requested by #174 is released, thus allowing blackboard data to be stored on the Node entity (which itself may contain additional data). An illustration of this feature is the following tree
Let's say that Walk is a Node with
DynamicBuffer<Waypoints>
, and thus takes up a lot of memory. Without Reference Nodes, each Walk Node in this tree will have its own set ofDynamicBuffer<Waypoints>
. Of course, this could be solved by having the blackboard store a commonDynamicBuffer<Waypoints>
at the root Node as usual, but too many behavior-specific data stored in the root can cause too many unique chunk archetypes.However, with Reference Nodes, the Walk Node can be represented by a single entity with only one
DynamicBuffer<Waypoints>
. As a result, each time any Walk Node is executed, in reality it will be the Reference Walk Node whose data is being accessed and modified.This change could be implemented by modifying the conversion process for the Convert And Destroy workflow. Multiple indices in the BT data structure could point to the same Node/Entity, if, say, a
ReferenceNode
Monobehaviour is present.ReferenceNode
has a GameObject field which points to the "real" Node to use.If this feature is deemed useful, but the maintainer is too busy, I'd like to volunteer to create a PR for this.
Beta Was this translation helpful? Give feedback.
All reactions