Thank you, for the link, this is what I’m looking for.
Gave this a try yesterday, and it looks super promising! And definitely a better UX and feel compared to things on the asset store so far. I really want to use this! 
I had a few questions when trying to move over my simple trees I made from Behavior Designer over to this
- In Behavior designer, I have these ‘abort types’ on the nodes. If the conditional ‘Can use Ability’ ever returns true, it will abort those further down the tree.
The closest thing I was able to find to replicate this, was to kinda ‘inverse’ this, and have the abort type on the last node
is this the best way?
-
Are there more complex examples available somewhere? The sample doesn’t seem to give much depth, and doesn’t feel super realistic.
-
Similar to the above, I’m able to ‘abort’ higher up in the tree if some kind of event happens. It seems I’m able to use
tree.Restart()in code to do a similar effect I want here. Which is good, since I couldn’t find an immediately obvious way to trigger graph events from code? How would you approach that?
Thanks for the work on this, I have no idea why this hasn’t gotten more coverage! CodeMonkey where are you! 
total game changer!
2 Likes
One last thing while I was testing, this behavior was unexpected to me. I would’ve thought the ‘abort if’ node would abort its children as well. But it doesn’t seem to?
Sorry if I’m missing some docs, i think i’ve read them all but might be missing something 
That is good to hear about the performance, as I will be using 200-400 agents at a time, non ECS for now.
Anything to keep in mind? Previously I was using a tick manager to control which agents ran and have them offset frame since I didn’t need them doing things EVERY frame, especially if they’re waiting for an animation or something.
Thoughts, or is that just overkill?
Hi Donurks,
We did find a regression / bug with components.
This will be fixed in the next release, we are testing the fixes right now.
Thanks for reporting!
2 Likes
With that amount of agents, I would try without first, and check if you need to optimise later.
I don’t believe the behavior package should cause any slowdown at this scale.
1 Like
@Darren_Kelly What do you think about using this behaviour tree to create Dialogue system? Could it be a good idea?
I think that should be doable yes, and not a bad idea!
@Darren_Kelly Is there any way to create customized Blackboard variables for the Unity localization package and getting a function like the OnValidate for the behaviour graph?
Thanks! The image showed me the answer: you use a blackboard.
BB is common but in my experience across both engines, you end up spending a lot of time abstracting and that’s not very Unity-like.
A much nicher and easier alternative can be seen Panda BT. All it does is execute user code that reside in attached mono. The user code is responsible for world state peek/poking and the BT is only an execution controller. This is extremely good because that’s how the rest of unity functions so you don’t need to shuffle various ways of thinking, it’s also less abstract so you don’t waste as much time.
Now, Panda uses reflection, which isn’t ideal in hot path but most of the time BT executes things at a low frequency and in my experience, the gain in usability far outweight the slight loss in perf. Also BT code usually spends copious amount of time in world queries using physics or navmesh samples and this far outweights (also) the loss in reflection.
Finally the biggest advantage of Panda is how terse node code is. There is near zero scaffolding, in contrast, the current direction you’re aiming for is excruciatingly verbose with half the code i’ve seen being scaffolding because EACH NODE needs its own class.
You need to think in terms of Unity production: iteration time is the most important, not performance, and most of the time we keep the prototyping code and release, only optimizing hot path.
To that end, I recommend you take a look at uNode which allows both reflected and hard coded nodes.
To summarize: less abstraction, less layers of thinking, terser node code, keeping BB for those coming from Unreal and keep the hard coding for hot path or mobile.
2 Likes
The App UI package that Behaviour depends on keeps adding App UI Shaders to the preloaded shaders section of Graphics settings. I’ve submitted a bug report (IN-85950) but under a thread for App UI a Unity staff member said that is an internal package and doesn’t receive support. Regardless, I want to use Behaviour but I don’t want any extra resources being added to my builds.
Thank you!
Hey @fendercodes,
First let me apologise for the delayed response. I’m on some time off and took a break from monitoring the forums. I think the team wasn’t sure how to respond as some of the information was with me, but they’re aware now. 
We’re in touch with the AppUI team and I want to reassure you that this behavior will be changed. The thing is Behavior and other users of AppUI can also be built for runtime (i.e. Struckd includes Behavior in it). You can safely remove these shaders from the list and we’ll get the default behavior changed so they’re not added implicitly.
This might take some time as the AppUI team is also away at the moment but they’ll be back soon and help with this. Please rest assured we’re supported by them and issues related to Behavior usage of AppUI can be reported to us.
1 Like
Gotcha. It would be great if we could avoid having anything included in our runtime builds unless absolutely necessary.
Regarding this specific shader, I can’t remove it from the Preloaded Shaders list because it gets re-added automatically.
Sorry for the late reply @AndreaGalet,
We have been very busy trying to get as many issues solved as we can for the upcoming release.
I don’t follow exactly you mean sorry.
Do you have an example? A code example would be even better.
There definitely should be a way to somehow integrate with the localization package although I have not tried this myself to provide a solution.
I have made this example in which i would like to set the Localized string reference as a node referenced variable but it gets me an error, I think because the graph can not serialize this variabile like the inspector does, so i manually set a key and phrase string as a preview to show in the graph and then pass the key parameter on the text object that i spawn when the dialogue start
Definitely! We’ll get that fixed asap There will be a delay due to various times off booked but it shouldn’t take too long.
Hi @AndreaGalet,
I pulled the package myself and tried to investigate a bit.
You are correct with there being an issue with serialization, right now we not supporting simple serializable types like the LocalizedReference.
In the next version we are adding a log warning about non supported types.
We do want to support these types in the future!
I will bring this up with the team. Some workaround like you mentioned using a string that holds the loca ident key & another string or so for preview in the node is the best I can think of for now.
I am assuming you can somehow grab the loca text info from the localization pacakge system using a simple loca identifier key as a string.
2 Likes
What I will do is spawning the prefab with the “TextMeshPro” component and the “Localize string Event” component, than getting the “Localize string Event” component and set the String Reference with my “key” variable to show the correct localizion. All this done inside my customized Graph node script
1 Like
Yes, that makes sense and it’s a good workaround for now.
I can let you know when we have better support for this use case.
When we are tackling the serialization task, I will make sure we test this case.
Thanks for the report and I hope your Dialogue system turns our great!
2 Likes
