This is absolutely amazing. Thank you for all the hard work you have put into this.
Me and a collaborator were wondering if this is compatible with team create sessions. If not, could we see any future improvements to the plugin that would allow this functionality? We would love to have real-time feedback from our edits.
As long as only one person is editing a tree at one time it should be fine. Don’t do it otherwise
Its a very powerful tool. Thank you a lot!
I’m not sure if I’m understanding the success decorator correctly… How does it work?
Is there a way to simulate the repeater decorator or do we have to run this in the main server?
Hello, quite the interesting tool you have here! Does it works/blends well with rojo?
This is super nice, I’m loving it so far. The modules seem really lightweight.
What is the reason to restrict trees to one directory? I generally want to store my trees next to the objects they are aplicable for, or otherwise wherever I want. I’m doing a couple of forks in the plugin to create trees in the current selection, and have them set up based on a collectionservice tag rather than a directory. Also forking TreeCreator to create and cache directly from the treeFolder instance instead of from a treeIndex.
Also, I was experiencing big frame drops lasting about a second every time I opened/closed the node editor or added/removed nodes (only in my game place, not on an empty baseplate). I narrowed it down to the one line doing ChangeHistoryService:SetEnabled(). What is the purpose of this? ChangeHistory waypoints don’t get set via plugins unless explicitly called with SetWaypoint. I commented this out and it completely solved the problem, and so far I can’t tell if there are ill effects.
Other feedback:
- it would be cool if there was an option to automatically set node priority based on X position relative to sibling nodes; this seems like the general useage.
- Would be nice to have box select to move
- Would be nice if moving a node would also move all of its descendant nodes together with it
- If I accidentally delete a tree folder while I have it open (accidentally hit DEL or forget the F shortcut), then when I undo to bring the folder back, it’s broken and won’t open
It was my ugly way of stopping folder changes to be undone on ctrl z, since the plugin is based around a physical folder with physical data/valuebases and sometimes change history messed things up
I haven’t touched this plugin in a long while though since I haven’t had the use to work with behavior trees anymore, and I think I found a nicer solution third party. But when I find the time I’ll likely polish it up a bit
If anyone would want to use the same UI/assets and make it less spaghetti I’d be fine with that too
Consider yourself forked!
Forks to the plugin:
- I made the nodes less hardcoded so it’s less of a headache to add new node types, like Repeat and Tree
- Support for nodes with parameters
- There is an explicit root node, so you can change the tree root without needing to destroy a bunch of nodes until the autoselected root happens to be the one you want.
- Node colors by category (composite/decorator/leaf/root) rather than by individual node type. I think this is easier to read at a glance.
- When you drag a node around, all descendant nodes will move with it
- After dragging a node, it and its siblings index order is automatically resorted based on X position
- Behavior tree folders can be created anywhere, instead of locked to a single directory for all of them. BehaviorTreeCreator caches directly by the folder instance instead of a string tree index.
- The node info in the help window is dynamically populated from the list of node types in the NodeInfo module.
- Random weight inputs will round up decimal inputs, as these aren’t supported with the random weighting implementation
- Pretty curvy lines obviously
Forks to BehaviorTrees2/BehaviorTreeCreator:
- Trees return their state when you call :run()
- Added Repeat node
- Added Tree node, which will pass a result from another tree. This new node allows tree reusability, which I imagine would be super handy for lots of NPC classes with similar AI.
- Added TreeCreator:SetTreeID(treeId, treeFolder), to associate trees with tree nodes based on the string TreeID parameter.
- Did a little bit of organization in the ProcessNode algorithm to make it easier to read and more intuitive to add new node types. Mainly, consolidated the node traversal nested loops which appeared in a few places into a single iterator function.
- Previously, decorators could only be adorned directly to tasks, and they would have no function if adorned anywhere else. They now can be put anywhere or even chained together, and will work as expected. I changed the way decorators work internally, but preserved the pretty clever and efficient tree traversal system that BehaviorTrees2 already had, so it should still be just as fast.
- Success/fail nodes can act as a leaf if left dangling
- Changed success/fail/running node states to number enums instead of strings, so the tree doesn’t have to do string comparisons. Should be a tiny bit faster.
- Changed tasks to report their status by returning a status number enum, instead of calling a function on self
- Slightly changed node constructors
- Changed TreeCreator:Create parameters from obj, treeFolder to treeFolder, obj. Made obj optional.
Not fully tested, but if anyone’s interested, this is what I have so far: ForkedBTrees.rbxm (61.0 KB)
And here is quick test place: BTreeForking.rbxl (83.3 KB)
Edit: made a post- BehaviorTrees3 + BTrees Visual Editor v3.0
This is great. Everything I wanted to do but didn’t really have the time for. Thanks !
I really like some of the UI changes like the bezier line connections too
Ik im late but is this visual scripting?